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Compilers  for  polymorphic  languages  can  use  run-time  type  inspect!  on  to  support  advanced  imple¬ 
mentation  techniques  such  as  tagless  garbage  collection,  polymorphic  marshalling,  and  flattened 
data  structures.  I  ntensional  typeanalysis  is  a  type-theoretic  framework  for  expressing  and  certify¬ 
ing  such  type-analyzing  computations.  Unfortunately,  existing  approaches  to  intensional  analysis 
do  not  work  well  on  quantified  types  such  as  existential  or  polymorphic  types.  This  makes  it  im¬ 
possible  to  code  (in  a  type-safe  language)  applications  such  as  garbage  collection,  persistency,  or 
marshalling  which  must  be  able  to  examine  the  type  of  any  run-time  value. 

We  present  a  typed  intermediate  language  that  supports  the  analysis  of  quantified  types.  In 
particular,  we  provide  both  type-level  and  term-level  constructs  for  analyzing  quantified  types. 
Our  system  supports  structural  induction  on  quantified  types  yet  type  check!  ngremainsdecidable. 
We  also  show  that  our  system  is  compatible  with  a  type-erasure  semantics. 

Categories  and  Subject  Descriptors:  D.3.3  [Programming  Languages]:  Language  Constructs 
and  Features— Polymorphism;  D.3.4  [Programming  Languages]:  Processors— Comp/'/ers;  F.3.3 
[Logic  and  Meanings  of  Programs]:  Studies  of  Program  Constructs— TypeStructure 

General  Terms:  Languages,  Verification 

Additional  Key  Words  and  Phrases:  Certified  Code,  Runt!  me  Type  Dispatch,  Typed  Intermediate 
Languages,  Intensional  Type  Analysis 


1.  INTRODUCTION 

Run-time  type  analysis  is  used  extensively  in  various  applications  and  pro¬ 
gramming  situations.  Run-time  services  such  as  garbage  collection,  dynamic 
linking,  and  reflection,  applications  such  as  marshalling  and  pickling,  type- 
safe  persistent  programming,  and  unboxing  implementations  of  polymorphic 
languages  all  analyze  types  at  runtime.  Most  existing  compilers  use  untyped 
intermediate  languages  for  compilation;  therefore,  they  support  run-time  type 
inspection  in  a  type-unsafe  manner.  I  n  this  paper,  we  present  a  statically  typed 
intermediate  language  that  allows  run-time  type  analysis  to  decoded  within 
the  language.  This  allows  us  to  leverage  the  power  of  dynamically  typed  lan¬ 
guages,  yet  retain  the  advantages  of  static  type  checking. 

Supporting  run-time  type  analysis  in  a  type-safe  manner  has  been  an  active 
area  of  research.  This  paper  builds  on  existing  work  [Harper  and  Morrisett 
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1995;  Crary  et  al.  1998]  and  makes  several  important  new  contributions.  We 
show  how  to  support  analysis  of  all  well-formed  quantified  types,  with  bound 
variables  ranging  over  arbitrary  kinds,  at  both  the  term  level  and  the  type 
level.  At  the  term  level  this  enables  programs  to  analyze  run-time  values 
such  as  function  closures  and  polymorphic  data  structures.  At  the  type  level, 
type  analysis  provides  accurate  specifications  for  term-level  type-analyzing 
programs.  In  addition,  type  transformations  (such  as  those  performed  dur¬ 
ing  closure  conversion  and  CPS  conversion),  that  could  hitherto  be  expressed 
only  in  a  meta  language,  can  now  be  expressed  within  the  type  language  it¬ 
self  [Shao  et  al.  2002].  We  prove  that  the  language  is  sound  and  that  type 
reduction  is  strongly  normalizing  and  confluent.  Finally,  we  providea  transla¬ 
tion  to  a  language  with  type  erasure  semantics. 

The  rest  of  this  paper  is  organized  as  follows.  I  n  Section  2  we  argue  the  case 
for  intensional  analysis  of  quantified  types,  and  describe  the  obstacles  on  the 
possible  roads  to  it.  Section  3  introduces  our  intensional  polymorphic  lambda 
calculus  Xf,  equipped  with  polymorphic  kinds,  which  allow  us  to  make  use  of 
kind  parametricity  at  the  type  level  in  order  to  restore  the  inductive  structure 
of  the  base  kind.  We  also  present  some  semantic  properties  of  A“  and  examples 
of  its  applications  in  Section  3.  A  possible  path  for  implementing is  outlined 
in  Section  4,  where  we  develop  a  language  for  intensional  type  analysis  of 
quantified  types  which  has  type-erasure  semantics,  and  in  Section  5,  where 
we  show  how  to  translate  terms  into  it.  A  brief  review  of  the  related  work 
can  be  found  in  Section  6,  and  proofs  of  the  properties  of  A  “  are  included  in  the 
Appendix. 

2.  MOTIVATION  AND  APPROACH 

The  core  issue  that  we  address  in  this  paper  isthe  design  of  a  statically  typed 
intermediate  language  that  supports  run-time  type  analysis.  Why  is  this  im¬ 
portant?  Modern  programming  paradigms  are  increasingly  giving  rise  to  ap¬ 
plications  that  rely  critically  on  type  information  at  run  time,  for  example: 

— ]  ava  adopts  dynamic  linking  as  a  key  feature.  To  ensure  safe  linking,  an  ex¬ 
ternal  module  must  bedynamically  verified  to  satisfy  the  expected  interface 
type. 

—A  precise  garbage  collector  must  keep  track  of  all  live  heap  objects,  and  for 
that  type  information  must  be  kept  at  run  time  to  allow  traversal  of  data 
structures. 

— I  n  a  distributed  computing  environment,  code  and  data  on  one  machine  may 
need  to  be  pickled  for  transmission  to  a  different  machine,  where  the  un- 
pickler  reconstructs  the  data  structures  from  the  bit  stream.  If  the  type  of 
the  data  is  not  statically  known  at  the  destination  (as  is  the  case  for  the 
environment  components  of  function  closures),  the  unpickler  must  use  type 
information,  encoded  in  the  bit  stream,  to  correctly  interpret  the  encoded 
value. 

-Type-safe  persistent  programming  requires  language  support  for  dynamic 
typing:  the  program  must  ensure  that  data  read  from  a  persistent  store  is  of 
the  expected  type. 

ACM  Transactions  on  Programming  Languages  and  Systems,  Vol.  TBD,  No.TDB,  Month  Year. 


Intensional  Analysis  of  Quantified  Types 


3 


—Finally,  in  polymorphic  languages  like  ML,  the  type  of  a  value  may  not  be 
known  statically;  therefore,  compilers  have  traditionally  used  inefficient, 
uniformly  boxed  representation.  To  avoid  this,  several  modern  compilers 
[Shao  and  Appel  1995;  Shao  1997a;  Tarditi  et  al.  1996]  use  run-time  type 
information  to  support  unboxed  representation. 


Most  existing  compilers  use  an  untyped  intermediate  language  for  compiling 
code  that  involves  run-time  type  inspection.  They  reify  types  into  values  and 
discard  type  information  at  some  early  stage  during  compilation.  However, 
this  approach  is  infeasible  in  a  certifying  compiler  [Necula  1998]. 

Codecertification  is  appealing  for  a  number  of  reasons.  I  n  a  certifying  frame¬ 
work,  one  need  not  trust  the  correctness  of  the  compiler  that  generated  the  cer¬ 
tified  code;  instead,  one  can  verify  that  the  generated  code  satisfies  the  proper¬ 
ties  it  claims,  for  instance  type  safety,  or  a  specific  security  policy.  Checkingthe 
correctness  of  a  compiler-generated  proof  (of  a  program  property)  is  much  eas¬ 
ier  than  proving  the  correctness  of  the  compiler.  Furthermore,  with  the  growth 
of  web-based  computing,  programs  are  increasingly  being  developed  at  remote 
sites  and  shipped  to  clients  for  execution.  Client  programs  may  also  download 
modules  dynamically  as  they  need  them.  In  this  context,  the  compiler  may 
not  even  be  known  to  the  client,  and  trusting  it  is  not  sufficient  either— the 
client  must  now  also  trust  the  medium.  For  such  a  system  to  be  practical,  a 
client  should  be  able  to  accept  code  from  untrusted  sources,  but  have  a  means 
of  verifying  its  behavior  before  execution.  This  again  requires  compilers  that 
generate  certified  code. 

A  necessary  step  in  building  a  certifying  compiler  is  to  have  the  compiler 
generate  code  that  can  be  type-checked  before  execution.  The  type  system  en¬ 
sures  that  the  code  uses  only  granted  resources,  makes  legal  function  calls,  etc. 
Generated  code  which  performs  run-ti  me  type  analysis  must  also  be  verifiable 
in  this  type  system. 

Moreover,  type-safe  run-ti  me  type  analysis  is  also  required  for  type-safe  im¬ 
plementations  of  runti  me  services.  The  safety  of  a  mobi  le  code  system  depends 
not  only  on  the  downloaded  code,  but  also  on  the  safety  of  all  the  applications 
and  services  that  the  runti  me  system  provides  (si  nee  the  downloaded  code  may 
execute  these  applications).  These  include  services  such  as  garbage  collection, 
linking,  etc.  Typically,  this  code  constitutes  the  trusted  computing  base  of  the 
system— it  is  assumed  that  the  code  is  correct.  H  owever,  there  are  significant 
advantages  to  independently  verifying  these  runtime  services.  Lifting  these 
services  out  of  the  trusted  computing  base  makes  the  system  more  reliable. 
The  services  can  be  then  structured  as  libraries,  offering  opportunities  for  code 
reuse. 

Finally,  it  is  essential  to  support  analysis  of  quantified  types.  Most  type¬ 
analyzing  applications  must  handle  arbitrary  heap  values.  For  example,  a 
garbage  collector  needs  to  traverse  all  live  data  structures  in  the  heap.  I  n  a 
type-preserving  compiler,  a  closure  would  have  an  existential  type  [M  inamide 
et  al.  1996]  and  a  polymorphic  function  would  have  a  polymorphic  type.  Thus 
analysis  of  quantified  types  is  essential  in  supporting  these  applications. 
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2.1  Background 

Harper  and  Morrisett  [1995]  proposed  intensional  type  analysis  and  presented 
a  type-theoretic  framework  for  expressing  computations  that  analyze  types  at 
run  time.  They  considered  a  language  with  operators  for  type  analysis,  both  at 
the  term  level  and  at  the  type  level.  Type-dependent  primitive  functions  use 
these  operators  to  analyze  types  and  select  the  appropri  ate  code.  For  example, 
suppose  that  arrays  of  values  of  type  int  and  real  have  specialized  representa¬ 
tions  (with  types,  say,  intarray  and  realarray),  and  are  therefore  accessed  using 
special  subscript  functions  intsub  and  realsub,  while  arrays  of  elements  of  any 
other  typer  have  the  default  boxed  representation,  have  type  boxedarrayr,  and 
are  subscripted  using  boxedsub  [r].  A  polymorphicsubscript  function  for  arrays 
might  be  written  using  a  term-level  type  analysis  operator  typecase  as  the  fol¬ 
lowing  pseudo-code: 

sub  =  Aa.  typecase  a  of 
int  ^intsub 
real  realsub 
(3  ^  boxedsub  [/?] 

Thus  sub  analyzes  thetypea  of  thearray  elements  and  returns  the  appropriate 
subscript  function. 

Finding  a  type  for  this  subscript  function  is  more  interesting,  because  it  can 
be  instantiated  to  have  any  one  of  the  types  intarray  — >  int  ^  int,  realarray  — > 
int  real,  and  Va.  boxedarraya  ^  int  ^  a.  Since  the  type  of  an  instance  of 
sub  depends  on  the  type  argument,  in  order  to  assign  a  type  to  the  function  we 
need  a  type-level  construct,  say  Typecase,  that  parallels  the  typecase  analysis 
at  the  term  level.  I  n  general,  this  facility  is  crucial  since  many  type-analyzing 
operations  like  flattening  and  marshalling  transform  types  in  a  non-uniform 
way.  The  subscript  operation  would  then  be  typed  as 

sub  :  Va.  Array  (a)  — ^  int  — ^  a 
where  Array  =  Aa.  Typecase  a  of 

int  intarray 

real  ^  realarray 
/?  boxedarray  /?. 

TheTypecase  construct  in  the  above  example  is  a  special  caseof  theTyperec  con¬ 
struct  of  Harper  and  Morrisett  [1995],  which  supports  primitive  recursion  over 
the  monotypes  (type  constructors)  of  their  language  Their  term  language 
cannot  express  general  recursion,  either,  and  is  also  equipped  with  a  construct 
for  primitive  recursion  over  types. 

2.2  The  Problem 

The  language  of  Harper  and  Morrisett  only  allows  the  analysis  of  monotypes; 
it  does  not  support  analysis  of  types  with  binding  structure  (e.g.,  polymorphic 
or  existential  types).  Therefore,  type  analyzing  primitives  that  handle  poly¬ 
morphic  code  blocks,  or  closures,  cannot  be  written  in  their  language.  The 
types  in  their  language  (in  essence  shown  in  Figure  1)  are  separated  into  two 
universes,  constructors  and  types.  The  constructor  calculus  is  a  simply  typed 
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K  ::=  Q  I  K.  ^  k' 

T  ::=  int  I  r  — >  r'  I  Q:  I  Aq::k.t  \  r  t'  \  Typerec  r  of  (Tint; 
cr  ::=  T  I  Vo; :  k.  cr 

Fig.  1.  Thetypelanguageof  Harper  and  Morrisett 


lambda  calculus,  with  no  polymorphic  types.  The  Typerec  operator  analyzes 
only  constructors  of  the  base  kind  Ci\ 

int  :  Q, 

:  n^n^n 

The  kinds  of  the  arguments  of  these  constructors  do  not  contain  any  negative 
occurrences  of  the  kind  (that  is,  occurrences  to  the  left  of  an  odd  number  of 
arrows).  Thus  the  kind  is  inductive.  The  Typerec  operator  provides  a  form 
of  primitive  recursion  over  this  inductively  defined  set  of  types.  Each  instance 
of  Typerec  must  specify  the  result  of  the  analysis  in  the  case  of  the  nullary 
constructor  int,  as  well  as  an  operator  to  combine  the  subterms  ti  and  t2  of  a 
function  type  n  ^  t2  and  the  results  of  the  iteration  over  them.  The  reduction 
rules  for  Typerec  can  be  written  as 

Typerec  int  of  (Tint;  T_^)  Tint 
Typerec  (n  ^  T2)  of  (Tint;  t_) 

^  Ti  (Typerec  ti  of  (Tint;  t_^))  T2  (Typerec  T2  of  (Tint;  t_)). 

Operationally,  the  reduction  of  Typerec  examines  the  head  constructor  of  the 
type  being  analyzed  and  chooses  a  branch  accordingly.  I  f  the  constructor  is  int, 
the  type  reduces  to  the  Tint  branch.  If  the  constructor  is  of  the  form  ti  ->T2,the 
analysis  proceeds  recursively  on  its  subterms  n  and  t2.  The  Typerec  operator 
then  applies  the  t_^  branch  to  the  components  n  and  t2,  and  to  the  result  of 
the  iteration  over  these  components. 

Types  with  binding  structure  can  deconstructed  using  higher-order  abstract 
syntax.  For  example,  the  polymorphic  type  constructor  Vn  could  be  given  the 
kind  {n  ^  n)  ^  n,  so  that  the  type  Va  :  fi.a  ->  a  could  be  represented  as 
Vo  (Aa  :  n.a  ^  a).  It  would  seem  plausible  to  define  an  iterator  with  the 
reduction  rule 

Typerec  (Vn  t)  of  (Tint;  t_^;  tv)  Ty  t  (Aa :  Typerec  (ra)  of  (Tint;  t_^;  Ty)). 

H  owever  the  negative  occurrence  of  i  n  the  ki  nd  of  the  argument  of  V  n  poses  a 
problem:  this  iterator  may  fail  to  terminate!  Consider  the  foil  owing  example: 
Assuming  I  =  Xa  :  fi.a  and  Ty  =  A/3i  :  ^  A/32:f^  ^  (Vn/3i),  the 

following  reduction  sequence  will  goon  indefinitely: 

Typerec  (Vn /)  of  (Tint;  t_^;  Ty) 

^  Ty/  (Aaifi.  Typerec  (/  a)  of  (Tint;  t_^;  Ty)) 

Typerec  (/  (Vn  /))  of  (Tint;  t_^;  Ty) 

^  Typerec  (Vn  I)  of  (Tint;  r_^;  ry) 
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Clearly  this  makes  the  standard  methcxi  of  typechecking  (by  comparing  normal 
for  ms  of  types)  fail.  More  generally,  the  existence  of  an  injectionVn  fromfi  ^ 
to  fl,  and  projections  from  fltofl  ^  fl,  for  instance 

A  =  Xa:^l.  Typerec  a  of  (/; 

x.-.n.x.-.n  n.  x.:n.  x.:n  ^  n.i; 

Xa' :  ri  ^  ^  ri.  A_:  ri  — >  ri. «'), 

such  that  A  (Vn  r)  =  T  for  al  I  T  of  ki  nd  ri  ri,  means  that  for  every  term  of  the 
untyped  lambda  calculus  one  can  construct  a  corresponding  well-formed  term 
of  this  type  language,  under  a  correspondence  which  is  preserved  under  the 
reductions  in  both  languages  and  maintains  the  equivalence  relation  on  their 
respective  normal  forms,  by  appropriately  inserting  applications  of  Vn  and  A 
(si  nee  every  untyped  lambda  term  can  be  translated  into  a  term  of  the  lambda 
calculus  with  recursive  types  and  given  the  type  ^.a.a  a  by  inserting  ap¬ 
propriate  applications  of  fold  and  unfold).  Since  equivalence  of  untyped  lambda 
terms  is  undecidable,  typechecking  a  language  with  the  above  Vq  and  Typerec 
is  also  undecidable. 

2.3  Requirements  for  a  Solution 

Let  us  present  the  central  requirements  for  supporting  intensional  analysis  of 
quantified  types  in  a  typed  intermediate  language. 

Consider  a  type-directed  serializer  that  converts  a  value  of  an  arbitrary  type 
to  external  representation.  We  will  show  that  at  the  term  level,  the  analysis 
must  proceed  inside  a  quantified  type.  Suppose  we  want  to  pickle  the  closure 
of  a  function  of  type  n  ^  t2.  After  type-preserving  compilation,  this  closure 
may  be  represented  as  a  term  of  an  existential  type  similar  to3aenv-^-ae„v  x 
{aenv  X  Ti  ^  T2),  where  the  type  Uenv  of  the  environment  is  held  abstract.  A 
general  pickier  should  process  this  type  as  any  other  existential,  and  analyze 
its  body;  thus  it  will  have  to  analyze  the  witness  type  for  aenv  Even  if  the 
pair-and-code  part  is  hard-coded  as  a  special  case,  the  pickier  must  inspect  the 
witness  type  in  order  to  pickle  the  environment.  A  similar  issue  arises  in  the 
comparison  of  two  values  of  an  existential  type. 

I  n  a  type-preserving  compiler  every  phase  transforms  terms  as  well  as  their 
types  to  maintain  type-correctness.  The  type  transformations  are  defined  in¬ 
ductively  on  the  structure  of  types.  For  example,  closure  conversion  would 
transform  types  as  follows: 

|int|  =  int 

|nXT2|  =  |ri|x|r2| 

|n^T2|  =  3Q;:ri.Q;x(Q;x|Ti|  ^  |t2|) 

Such  type  transformations  [Harper  and  Lillibridge  1993]  are  conventionally 
expressed  in  a  metalanguage.  However,  when  transforming  polymorphic  types 
like  Va:  Li.  T,  it  is  not  obvious  in  general  how  to  transform  a  (and  other  normal 
forms  with  free  variables).  A  metalanguage  transformation  must  define  |a|  as 
some  type  in  the  target  language.  Since  a  can  be  instantiated  (at  the  point  of 
type  application)  to  any  type  r',  it  is  "too  early"  to  choose  some  type  construc¬ 
tor  for  |a|.  The  only  reasonable  alternative  seems  to  be  to  define  |a|  as  another 
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variable/3,  appropriately  introduced;  in  turn  this  implies  that  the  transforma¬ 
tion  has  been  shifted  to  the  type  arguments  r'.  This  is  not  always  possible, 
because  the  transformation  may  depend  on  the  context  of  a  in  r;  worse  yet, 
in  a  language  with  type  analysis  a  may  be  analyzed  in  r,  and  it  would  be  im¬ 
possible  to  invert  the  transformation  of  \t'\  so  the  results  of  its  analysis  are 
consistent  with  the  source. 

Oneway  out  is  to  use  intensional  type  analysis  to  specify  the  transformation 
within  the  language  itself,  which  gives  the  additional  advantage  that  proving 
type  correctness  of  the  transformation  reduces  to  checking  well-formedness. 
Of  course  this  is  only  possible  if  the  analysis  is  defined  on  quantified  types. 
A  further  requirement  is  that  |a|  must  be  defined  as  a  normal  form,  so  that 
the  transformation  can  "continue  operating”  appropriately  on  the  arguments 
at  type  applications,  which  are  left  unchanged. 

Another  serious  problem  in  analyzing  quantified  types  involves  both  the 
type-level  and  the  term-level  operators.  Recent  work  on  typed  compilation  of 
ML  andj  ava  [Shao  1998;  1999;  League  et  al.  1999]  has  shown  how  to  compile 
both  languages  using  higher-order  type  constructors  with  arbitrarily  complex 
kinds;  there  have  been  so  far  no  results  on  type-preserving  compilation  of  these 
languages  which  uses  a  fixed  set  of  kinds.  Consequently,  typed  intermediate 
languages  such  as  FLI  NT  [Shao  1997b]  and  Tl  L  [Tarditi  1996]  are  based  on 
calculi  derived  from  [Girard  1972;  Reynolds  1974],  in  which  the  quantified 
type  variables  are  not  restricted  to  a  base  kind  Li  and  can  have  arbitrary  kinds. 
In  the  case  of]  ava  [League  et  al.  1999],  existential  quantification  over  higher 
kinds  appears  in  the  types  of  objects,  which  are  prime  candidates  for  inten¬ 
sional  type  analysis  for  the  support  of  reflection.  To  do  anything  nontrivial 
when  analyzing  a  package  of  type  3a:  k.  t  at  the  term  level,  we  must  open  the 
package,  for  which  we  need  to  know  the  kind  n.  Having  an  infinite  number 
of  branches  in  the  typecase  so  we  can  handle  all  possible  kinds  is  impractical. 
The  alternative  to  restrict  type  analysis  to  a  finite  set  of  kinds  would  make  it 
impossible  to  use  the  known  type-preserving  compilation  schemes  for  ML  and 
]  ava. 

Furthermore,  by  generalization  of  the  result  of  Section  2.2  it  can  be  shown 
that,  if  the  representation  of  quantified  types  is  based  on  higher-order  abstract 
syntax,  when  the  kind  of  the  bound  variable  is  a  known  constant  in  the  corre¬ 
sponding  branch  of  theTyperec  construct,  decidability  of  type-checking  is  lost. 

This  leads  us  to  the  following  set  of  requirements  for  the  intensional  type 
analysis.  First,  the  analysis  must  be  primitively-recursive,  in  the  style  of 
Harper  and  Morrisett,  the  expressiveness  of  which  has  been  established.  Sec¬ 
ond,  the  analysis  must  proceed  inside  the  body  of  a  quantified  type,  as  op¬ 
posed  to  mapping  all  quantified  types  to  the  same  result,  for  example.  Third, 
a  Typerec  term  analyzing  a  type  variable  must  be  a  normal  form.  Fourth,  the 
kind  of  quantified  variables  in  analyzable  types  should  not  be  restricted,  be¬ 
cause  this  would  prevent  the  use  of  the  current  compilation  techniques  for 
higher-order  typed  languages.  As  further  illustrated  in  Section  3.1,  many  in¬ 
ter  esti  ng  type-di  rected  operations  requi  re  these  propaties. 
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2.4  Problems  with  the  Use  of  deBruijn  Notation 

The  key  problem  in  analyzing  quantified  types  such  as  the  polymorphic  type 
Va :  ri.  a  a  is  to  determine  what  happens  when  the  iteration  reaches  a  free 
occurrenceof  the  bound  type  variablea,  or  more  generally  a  normal  formwhich 
does  not  have  a  (saturat^)  application  of  a  constructor  of  in  its  head. 

Crary  and  Wei  rich  [1999]  propose  the  use  of  deBruijn  indices  (i.e.,  natural 
numbers)  to  represent  quantifier-bound  variables.  To  analyze  quantified  types, 
the  iterator  carries  an  environment  that  maps  indices  to  types.  When  the  it¬ 
erator  reaches  a  type  variable,  which  is  now  represented  as  just  another  con¬ 
structed  type  (encoding  a  natural  number),  it  returns  the  corresponding  type 
from  the  environment.  This  method,  however,  has  several  major  problems: 

—The  analysis  is  restricted  to  types  with  quantification  only  over  variables  of 
kind  fl.  Extending  it  to  handle  a  larger  set  of  kinds  is  difficult,  since  one 
would  have  to  maintain  a  kind  environment  to  ensure  well-formedness. 
—The  technique  is  "limited  to  parametrically  polymorphic  functions,  and  can¬ 
not  account  for  functions  that  perform  intensional  type  analysis"  [Crary  and 
Weirich  1999,  Section  4.1].  For  example  polymorphic  and  existential  types 
such  as  Va:ri.  Typerec  a  of  . . .  are  not  analyzable  in  their  framework. 

—A  Typerec  term  analyzing  a  quantifier-bound  type  variable  (rather,  its  de¬ 
Bruijn  index)  is  not  in  normal  form,  hence  this  technique  cannot  be  used  to 
encode  type  transformations  associated  with  closure  conversion,  etc. 

—The  correctness  of  the  structure  of  a  type  encoded  using  deBruijn  notation 
cannot  be  verified  by  the  kind  language  (indices  not  corresponding  to  bound 
variables  go  undetected,  so  the  environment  must  provide  a  default  type 
for  them).  This  does  not  break  the  type  soundness,  but  opens  the  door  for 
programmer  mistakes. 

2.5  Our  Solution 

Toaccount  for  non-parametrically  polymorphic  functions,  we  must  analyze  the 
quantified  type  variable.  Moreover,  we  want  to  have  confluence  in  the  type 
language,  so  /3-reduction  should  be  transparent  to  the  iterator.  This  is  possi¬ 
ble  only  if  no  reduction  rules  apply  at  the  head  of  (Typerec  t  of  . . .)  when  r 
is  not  (a  saturated  application  of)  a  constructor  of  n.  Thus  the  analysis  "gets 
suspended"  when  it  reaches  a  type  variable  of  kind  (or  an  irreducible  appli¬ 
cation,  etc),  and  resumes  when  the  variable  is  substituted  with  a  constructed 
type.  For  example,  the  result  of  analyzing  the  body  a  ^  int  of  the  polymorphic 
typeVQ;:ri.Q;  ^  int  is 

Typerec  (a  ^  int)  of  (ript;  ry)  ^  r_^  a  (Typerec  a  of  (Tint;  Ty))  int  Tint. 

The  other  problem  is  to  analyze  quantified  types  when  the  quantified  vari¬ 
able  can  be  of  an  arbitrary  kind.  I  n  our  language  the  solution  is  similar  at  both 
the  type  and  the  term  levels:  we  use  kind  polymorphism!  We  introduce  kind 
abstractions  at  the  type  level  (Ax.  t)  and  at  the  term  level  (A\.e)to  bind  the 
kind  of  the  quantified  variable.  The  details  are  presented  Section  3. 

It  is  important  to  note  that  our  language  provides  no  facilities  for  kind  anal¬ 
ysis,  thus  every  type  function  of  polymorphic  kind  is  parametrically  polymor- 
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(kinds)  K 

(types)  T 

(values)  V 

(terms)  e 

Fig.  2.  Syntax  of  theA^  language 

r^r'  =  ((^)'r)r' 

\/a:K,.T  =  (V  [k])  (Aa ;  K.  r) 
V^x-  (Ax-  r) 

Fig.  3.  Syntactic  sugar  for  Xf  types 


::=  n  I  K  ^  k'  I  X  I  Vx-  K 

::=  int  I  ^  I  V  I  I  q;  I  Ax- r  |  XaiK.T  \  t[k\  \  T  t' 

I  Typerec[K]  r  of  (ri^;  tv;  t^) 

i  I  \  Aa:K.e  |  \x\r.e  \  fixa;:r.T; 

::=  I  a;  I  e  [k]^  I  e  [r]  |  ee'  \  typecase[T]  r' of  (eint;  e^;  ey;  e^+) 


phic.  Analyzing  the  kind  k  of  the  bound  variable  a  in  thetypeVQ;:^.  t  would  let 
us,  for  instance,  synthesize  a  type  of  the  same  kind,  for  every  kind  k.  This  type 
could  then  be  used  to  create  non-terminating  reduction  sequences  [H  arper  and 
Mitchell  1999]. 

3.  ANALYZING  QUANTIFIED  TYPES 

In  the  impredicative  calculus  the  polymorphic  types  Va:«;.T  can  be  viewed 
as  generated  by  an  infinite  set  of  type  constructors  V„  of  kind  {k  9)  ^  9, 
oneforeach  kind/t,  so  that  the  type  Va:K.T  is  represented  asV^  (Aq;:k.  t).  The 
kinds  of  constructors  that  can  be  used  to  create  types  of  kind  Li  would  then  be 

int  :  9 

:  9  ^  9  ^  9 

Vn  :  (Li  ^  Li)  ^  Li 

V„  :  {k  ^  9)  ^  9 

However,  having  an  infinite  number  of  V„  constructors  is  not  a  real  option; 
more  importantly,  all  of  them  have  kinds  with  negative  occurrences  of  Li  in 
their  domains.  We  can  replace  all  of  them  by  a  single  constructor  V  of  poly¬ 
morphic  kind  Vx-  (x  Ai)  — >  (where  x  stands  for  a  kind  variable)  and  then 
instantiating  it  to  a  specific  kind  before  forming  polymorphic  types.  Thus  our 
intensional  polymorphic  lambda  calculus  (with  syntax  shown  in  Figure  2) 
extends  with  pol  ymorphic  ki  nds  Vx-  k  and  adds  the  type  constructor  V  to  the 
type  language.  The  polymorphic  type  Va:  k.  t  is  now  a  derived  form  (Figure  3) 
represented  as  V[k]  (Aa  :  k.t);  the  construct  r  [k]  denotes  kind  application  at 
the  type  level. 

When  analyzing  a  type  r  (of  kind  9)  with  the  Typerec  operator,  the  argu¬ 
ments  of  the  outermost  type  constructor  of  t  must  be  passed  to  the  correspond- 
ing  branch  of  Typerec.  I  n  the  case  of  polymorphic  types  represented  using  V 
these  arguments  are  types  with  bound  variables  of  arbitrary  kinds.  Thus  the 
correspondi  ng  branch  of  the  operator  must  bi  nd  the  ki  nd  of  the  quantified  type 
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variable  to  a  kind  variable;  for  that  purpose  the  language  provides  kind  ab¬ 
straction  (Ax-  t)  at  the  type  level. 

Similarly,  when  analyzing  a  polymorphic  type  at  the  term  level,  the  con¬ 
struct  typecase  must  bind  the  kind  of  the  quantified  type  variable  to  a  kind 
variable,  which  necessitates  the  introduction  of  kind  abstraction  (a\.  e)  and 
kind  application  (e[K]  )  at  the  term  level.  A  term-level  kind  abstraction  must 
be  given  a  kind-polymorphic  type,  so  we  need  a  type  construct  v\.  r  that  binds 
the  kind  variablex  in  the  typer.  However  our  goal  is  to  ensure  that  all  types, 
now  including  kind-polymorphic  types,  can  be  analyzed.  As  with  polymorphic 
types,  the  solution  is  to  represent  the  type  v\.  r  as  the  application  of  a  type 
constructor  V^of  kind  (Vx-fi)  — >  fitoa  (type-level)  kind  abstraction  Ax-r.  Thus 
the  kinds  of  the  constructors  for  types  of  kind  are  as  follows. 

int  :  Q. 

V  :  vx.(x-f^)^f^ 

V""  :  (Vx.f^)^f^ 

The  kind  is  not  in  a  negative  positions  in  the  kind  of  any  of  these  con¬ 
structors'  argumeits,  hence  is  now  defined  inductively  by  these  construc¬ 
tors.  Typerec  is  then  the  iterator  over  this  kind.  To  save  space  in  figures  we 
use  desugared  syntax  for  Typerec  and  typecase,  with  their  branches  listed  in 
fixed  order  and  without  pattern  matching  for  their  parameters;  however  we 
use  friendlier  syntax  in  examples. 

The  static  semantics  of  Xf  is  displayed  in  Figures  4  and  5  as  a  set  of  rules 
for  judgments,  where  the  kind  environment  £  is  a  list  of  kind  variables. 

Perhaps  the  easiest  way  to  understand  the  semantics  of  Typerec  is  to  consider 
first  its  reduction  rules,  given  in  Figures.  Depending  on  the  head  constructor 
of  the  typer  being  analyzed,  Typerec  chooses  one  of  the  branches.  Similarly  to 
H arper/M or ri sett's  construct,  when  r  is  int,  the  result  is  the  Tint  branch,  and 
when  T  is  the  function  type  n  t2,  the  result  is  obtained  by  applying  the 
branch  to  the  components  n  and  t2  and  to  the  results  of  the  iteration  over 
them. 

When  analyzing  a  polymaphic  type,  the  reduction  rule  is 

Typerec[K]  (\/a:K'.T)  of  (rint;  r_^;  ry;  r^f) 

Ty  [k']  {Xa-.K'.r)  (Aa: k'.  Typerec[K]  r  of  (rint;  r_^;  ry;  r^f)). 

Thus  the  V-branch  of  Typerec  receives  as  arguments  the  kind  of  the  bound  vari¬ 
able,  the  abstraction  representing  the  quantified  type,  and  a  type  function  en¬ 
capsulating  the  result  of  the  iteration  on  the  body  of  the  quantified  type.  Since 
ry  must  be  parametric  in  the  kind  k'  (there  are  no  facilities  for  kind  analysis  in 
the  language),  it  can  only  apply  its  second  and  third  arguments  to  locally  in¬ 
troduced  type  variables  of  kind  n' .  We  believe  this  restriction,  which  is  crucial 
for  preserving  strong  normalization  of  the  type  language,  is  quite  reasonable 
in  practice.  For  instance  ry  can  yield  a  quantified  type  based  on  the  result  of 
the  iteration. 
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Kind  formation  S'tk 


S  \-  K  S  \-  k'  £,x^  h 
£  \-  K  ^  k'  £  \-  Vx-  K 


£■  h  A  £'r  K 
£  \-  e  £  \-  A.,a-.K, 


Type  formation  £’;AI-t  :  k 


£■  h  A 

£■;  A  h  int  : 

£■;  A  h  (^)  : 

£’;AI-V 

£■;  A  h  :  (Vx-  n)  ^  n 


S  \-  A  £’,x;AI-t:k  S\A\-t:  Vx-  ^  8  \-  k' 

£■;  A  h  Ax-  T  :  Vx-  K  £■;  A  h  r  [k']  :  k{k' /x} 


xeg 

^-hx 


Type  environment  formation  £■  h  A 


h  A  q:;k  in  A 
A  h  ci  :  k 


A,  a ;  K  h  T  : 
S]A\-\ol:k.t  :  k  ^  k' 


£]  A\-  T  ■.  k'  ^  K  S]  A\-  t'  :  K,' 
S]  A\-  T  t'  :  K 


A  h  r 
A  h  Tint 
A  h  rv 


K  S;  A  \-  :  H— 

Vx-  (x  ^  ^  (x  ^  k)  ^  K  £■;  A  h  :  (Vx-  H)  ^  (Vx-  k)  K 

£■;  A  h  Typerec[«;]  r  of  (rin,;  ry;  r^)  :  k 


Term  environment  formation  £’;AI-r 

^■l-A  £’;A|-r  £’;A|-t:Q 

£’;AI-£  £’;AI-r,a;:T 


Term  formation  £’;A;ri-e  :  t 

£-,A-,T're-.T  £]  A'r  t  ^  r'  ■.  Q.  ^’iAhT  £■,  x;  A;  T  h  e  :  t  £■;  A;  T  h  e  ;  V"^r  £■  h  k 

A;  r  h  e  :  t'  A;  F  h  A^X-  ^  •  '^'^X-  A;  F  h  e  [k]^  :  r  [k] 


£■;  A  h  F 
8]  A-^V  \-  i  :  int 


£’|-A  £’;A,a:/^;ri-e:r 
8]  A]T  \- ha.:  K.  e  :  VaiK.r 


A;  r  h  e  :  V  [k]  r  A  h  :  k. 
A;  r  h  e  [r^]  :  r 


£’;AI-r  x:rinr  8]  A-^T  ^x:t  \-  e  :  t' 

£’;A;ri-a::  :  r  8]  A]T  \- Xx:r.  e  :  r  ^  r' 


8-,A-Vh  e  :  r'  -*T  8]  A-,V  h  e'  :  r' 

8;A;r\-  ee'  :  r 


8;  A;r,x:T  \-  V  :  r 

8;  A-,r  \- 8\xx:t.v  :  r 

£■;  A  h  T  :  n 
£;A\-t'  :  n 

n 

where 

£■;  A;F  h  eint 

T  int 

T  ='^~^X1  •  •  -  Xn- 

£’;A;FI-e^ 

\fa :  £7.  \fa' :  £7.  r  (o;  — >  a') 

Vai :  Ki  . . .  am  • 

£’;A;FI-ev 

V^x-  Vo :  X  ^  "T  (V  [x]  o) 

T1  ^  T2 

£•;  A;  F  h  e„+ 

Vo :  (Vx-  O) .  T  (V^ o) 

A;  r  h  typecase[r]  of  (ejnt;  e_*;  ev;  e^)  :  rr' 


Fig.  4.  Formation  rules  of 
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Type  reduction  S\A\-ti^t2  ■■  k 


£■;  A,  o :  k'  h  r  :  K  :  k' 


X;  ^  h  r  :  Vx-  K  £  \-  k' 


A  h  (A«  :  k'.  t)  t' I— >  :  K  A  h  (Ax- t)  [k']  i— >  t{k'/x}  ■  ri{KVx} 

£';A|-r:K— >k'  A  h  r  :  Vx^  K  X  ^  fkv{T) 

£■;  A  h  Act :  K.  T  a  1-^  T  :  K  ^  k'  £';AI-  Ax-  t[x]  t  :  Vx^  k 

£■;  A  h  Typerecffi]  int  of  (rin,;  r^;  tv;  t^+)  :  k 
£■;  A  h  Typerec[K]  int  of  (Tin,;  tV,  \+)  "Tint  :  « 

£■;  A  h  Typerecfre]  r,  of  (rin,;  tv;  t^+)  t(  :  k 

£■;  A  h  Typerecfft]  T2  of  (rin,;  tv;  t^)  t^  :  k 

£■;  A  h  Typerec[K]  ((^)  n  T2)  of  (rin,;  r^;  tv;  t^)  t^  n  t{  T2  t^  :  k 

£■;  A,  o :  k' h  Typerecfft]  (r  o)  of  (Tint ;  T^ ;  Tv;  T^+)  I— >  t'  :  k 

£■;  A  h  Typerec[K]  (V  [k']  t)  of  (-Hn,;  t^;  tv;  t^+) 

I— »  Tv  [k^]  T  (Aa :  k'.  t')  :  k 

X;  h  Typerec[ft]  (t  [x])  of  (Tin,;  t^;  Ty;  t^)  t'  :  k 
£■;  A  h  Typerec[K]  (V^ t)  of  (vint;  t^;  tv;  t^)  t^  t  (Ax-  t')  :  k 

Fig.  5.  Seiected  A^  type  reduction  ruies 


The  reduction  rule  for  analyzing  a  kind-polymorphic  type  is 


Typerecf^]  (V\.  r)  of  (Tint;  r_^;  ry;  r^f) 

^  V  f)  (Ax-  Typerec[K]  r  of  (rint;  Ty;  Tyf))- 

Theargumentsof  theTyf  arethekind  abstraction  underlyingthe kind-polymor¬ 
phic  type,  and  a  kind  abstraction  encapsulating  the  result  of  the  iteration  on 
the  body  of  the  quantified  type. 

The  formation  rule  for  Typerec  then  follows  naturally  from  the  requirement 
that  the  above  reductions  preserve  well-formedness.  The  general  correspon¬ 
dence  between  the  ki  nd  of  a  constructor  of  and  the  ki  nd  of  its  Typerec  branch 
[Pfenning  and  Paulin-Mohring  1989]  is  in  essence  that  for  each  in  (a  posi¬ 
tive  position  in)  the  kinds  of  the  arguments  of  the  constructor  we  get  a  pair 
of  types,  one  of  kind  (the  subterm  itself)  and  the  other  of  the  kind  k  of  the 
result  of  the  iterative  invocation  of  Typerec.  However,  since  has  no  pairs  at 
the  type  level,  we  use  currying;  we  also  have  to  propagate  kind  quantification 
accordingly. 

Proofs  of  the  following  properties  of  the  type  language  of  A^,  which  entail 
decidability  of  its  type  checking  by  reduction  of  types  to  their  unique  normal 
forms,  can  be  found  in  Appendix  A. 

Proposition  3.1  (Strong  normalization).  Reduction  of  well -formed 
types  is  strongly  normalizing. 
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(Ax  :T.e)v  ^ 

e{v/x} 

(fixx:r.  f)  v'  ^ 

(f{fix  X :  T.  v/x'\)  v' 

(Aof :  K..  e)  [r] 

e{T /ol} 

(fix x:t.v)  [r'] 

(i;{fix  X :  r.  n/x})  [r'] 

(A^ X-  e)  ^ 

e{K,/x} 

(fix x\T.v)  [k]'*' 

(ti{fixx:r.  v/x})  [k]"*" 

e' 

e' 

e' 

e' 

eei  e'  ei 

V  e  ^  V  e‘ 

'  e  [r]  e'  [r] 

e  e'  [k]"*" 

typecase[r]  intof  (eint;  e^;  ey;  e^+)  e;„t 
typecase[r]  (n  ^  T2)  of  (eint;  e^;  ey;  e^)  [ri]  [T2] 

typecase[T]  (V[k]t')  of  (eint;  e^;  ey;  e^)  ey  [ref  [r'] 

typecase[r]  (vV')  of  (eint;  e^;  ey;  e^+)  e^+  [t'] 

e;£  h  r' 1-^*  !/':Q  i/' is  a  normal  form 

typecase[r]  t'  of  (eint;  e^;  ey;  e^+)  ^  typecase[r]  i/'  of  (eint;  e^;  ey;  e^+) 

Fig.  6.  Operational  semantics  of 

Proposition  3.2  (Confluence).  Reduction  of  wd  l-formed \‘f  types  is  con¬ 
fluent. 

At  the  term  level  type  analysis  is  carried  out  by  the  typecase  construct;  we 
do  not  define  it  as  an  iterator  since  the  term  language  already  has  a  recursion 
primitive,  fix.  Figure6displaysthe  operational  semantics  of  the  term  language 
of  A^,  which  shows  that  theV  branch  of  typecase  receives  the  kind  and  the  type 
abstraction  carried  by  the  type  constructor  V,  whiletheV^branch  gets  the  kind 
abstraction  carried  by  vt  The  static  semantics  guarantees  type  safety  of  Xf 
programs,  as  shown  in  Appendix  A. 

Proposition  3.3  (Type  Safety).  If  h  e  :  t,  then  ather  e  is  a  value  or 
there  exists  an  e'  such  that  \-  e'-.r  and  e  e'. 

3.1  Applications 

The  power  of  intensional  type  analysis  is  in  its  ability  to  break  the  abstraction 
barriers  raised  by  parametric  polymorphism.  As  a  consequence,  however,  like 
many  other  programming  language  features  intensional  type  analysis  "cuts 
both  ways"— many  useful  properties  of  programs  are  lost  in  a  language  that 
offers  it  in  its  plain  form.  Nevertheless  we  believe  its  use  is  appropriate  at 
certain  levels  of  an  implementation  of  a  programming  language,  which  need 
to  know  about  data  representation  held  abstract  at  higher  levels.  Typical  ex¬ 
amples  include  memory  management,  serialization,  and  reflection;  however 
the  detailed  development  of  such  examples  is  beyond  the  scope  of  this  paper. 
In  this  section,  we  illustrate  the  usefulness  of  type-level  and  term-level  anal¬ 
yses  of  types.  We  encode  a  type-safe  marshalling  primitive,  and  show  how 
type  classes  can  be  simulated.  The  interested  reader  may  refer  to  Monnier 
et  al.  [2001]  for  a  more  realistic  example  that  involves  type-checking  a  copying 
garbage  col  lector. 
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To  make  the  examples  slightly  more  readable  we  will  use  M  L-style  pattern¬ 
matching  syntax  when  writing  types  defined  by  Typerec.  I  nstead  of 

/  =  Xa:fl.  Typerec[K]  a  of  (Tint;  tv;  r^f) 
where  =  Aai :  fl.  Xa'^ :  k.  Xa2  '■ 

Tv  =  Ax.  Aa : X  — *■  •  Aa' :x  ^ 

Tyf  =  Aa :  (Vx-  ■  Xa' :  (Vx-  n)  ■ 

we  will  write 


./■(int) 

—  '^int 

/(«!  - 

>  a2) 

=  T/,{/(ai),/(a2)/ai,a2} 

/  (V  [x] 

a) 

=  Ty{Xai:x-  f  {aai)/a'} 

./(V^a) 

=  T^{^X-fio:[x])/a'}. 

3.1.1  Marshalling.  Oneof  the  examples  that  Harper  and  Morrisett  [1995] 
use  to  illustrate  the  power  of  intensional  type  analysis  is  based  on  the  exten¬ 
sion  of  M  L  for  distributed  computing  proposed  by  Ohori  and  Kato  [1993].  The 
idea  is  to  convert  values  into  a  form  which  can  be  used  for  transmission  over  a 
network.  An  integer  value  may  be  transmitted  directly,  but  a  function  may  not; 
instead,  a  globally  unique  identifier  is  transmitted  that  serves  as  a  proxy  at  the 
remote  site.  These  identifiers  are  associated  with  their  functions  by  a  name 
server  that  may  be  contacted  through  a  primitive  addressing  scheme.  The  re¬ 
mote  sites  use  the  identifiers  to  make  remote  calls  to  the  function.  H  arper  and 
Morrisett  show  how  to  define  types  of  transmissible  values  as  well  as  functions 
for  marshal  ling  to  and  unmarshalling  from  these  types  using  intensional  type 
analysis.  However,  the  predicativity  of  their  type  language  prevents  it  from 
handling  the  full  calculus  of  Ohori  and  Kato,  which  also  includes  the  remote 
representation  of  polymorphic  functions  and  remote  type  application. 

I  n  Xi  marshalling  of  polymorphic  values  is  straightforward;  in  fact  it  offers 
more  flexibility  than  the  calculus  of  Ohori  and  Kato  needs,  since  polymorphic 
functions  become  first-class  values,  and  polymorphic  types  can  be  used  in  re¬ 
mote  type  appi  ications.  Adapti  ng  the  constructs  of  H  arper  and  M  orrisett  to  Xf , 
we  introduce  a  type  constructor  IdiAi  — >  Ai.  A  value  of  type  t  has  a  global  iden¬ 
tifier  of  type  Id  T.  TheTyperec  and  typecase  operators  aresimilarly  extended,  for 
example,  the  following  rule  is  added  to  the  definition  of  type  reduction. 

TyperecfAt]  (Ht)  of  (Tint;  t^;  tv;  T^f;  Tid) 

^  T|d  T  (Typerec[K]  t  of  (Tint;  t_^;  tv;  Tyf;  Tid)) 

The  type  of  the  remote  representation  of  values  of  type  t  is  Tran  t,  defined  by 
Harper  and  Morrisett  using  intensional  analysis  of  t.  Values  of  type  TranT 
do  not  contain  any  abstractions;  all  the  abstractions  are  wrapped  inside  an  Id 
constructor.  We  can  extend  the  Harper/M  orrisett  definition  of  Tran  to  handle 
the  quantified  types  of  A^  as  follows. 

Tran  (int)  =  int 

Tran  («!  ^  02)  =  Id  (Tran  ai Tran  a2) 

Tran(V[x]Q;)  =  Id  (Va' :x- (Aai  :x- Tran  (a  ai))  a') 

Tran(V‘^a)  =  Id  (vV- (Ax- Tran  (a  [x]))  [x']) 

Tran  (Id  a)  =  Ida 
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To  clarify  the  connection  with  the  Typerec-based  representation,  we  write  the 
right-hand  sides  exactly  as  obtained  by  expanding  the  pattern-matching  syn¬ 
tax  introduced  earlier;  the  redexes  ostensibly  present  here  do  not  exist  in 
Typerec  notation.  The  last  clause  is  due  to  the  global  identifiers  being  mar¬ 
shalled  as  themselves. 

At  the  term  level  the  system  provides  primitives  for  creating  global  identi¬ 
fiers  and  performing  remote  invocations.^ 

newid  :  Vai :  Va2 :  (Tran  ai— >Tran  a2)^Tran  (Qfi^Q;2) 
rapp  :  Vcri :  ft.  Va2 :  Tran  (ai^a2)^Tran  ai— s-Tran  q;2 
newpid  :  (VQ;':x-Tran  (a  a'))  ^ Tran  (V  [x]  a) 

rtapp  :  V^x-^cr -X  ^  Tran  (V  [x]  a)  Va'  :x-  Tran  {a  a') 

For  completeness  in  our  system  we  also  need  to  handle  kind  polymorphism  and 
remote  kind  applications. 

newkpid  :  Va:  (Vx-  ^)-  (V^X-  Tran  (a  [x]))  ^  Tran  (V^a) 
rkapp  :  Va:  (Vx-  fi).  Tran  (V^a)  ^  V^X-  Tran  (a  [x]) 

Operationally,  given  a  function  or  a  polymorphic  value  respectively,  the  new-id 
functions  generate  a  new,  globally  unique  identifier,  and  tell  the  name  server 
to  associate  that  identifier  with  the  value  on  the  local  machine.  The  remote 
applications  take  a  proxy  identifier  of  a  remote  function  and  a  transmissible 
argument  value.  The  name  server  iscontacted  to  get  the  site  where  the  remote 
function  exists;  the  argument  is  sent  to  this  machine,  and  the  result  of  the 
application  transmitted  back  as  the  result  of  the  operation. 

Marshalling  and  unmarshalling  of  values  from  transmissible  representa¬ 
tions  are  performed  by  the  mutually  recursive  functions  M :  Va :  a  ^  Tran  a 
and  U  :Va:ri.  Tran  a  ^  a.  They  are  defined  as  follows  (using  pattern-matching 
syntax  and  implicit  recursion  instead  of  typecase  and  fix). 


M 

[int] 

=  Xx 

:  int.  X 

M 

[oti  - 

^  0:2] 

=  Xx 

:ai  ^  a2.  newid  [ai]  [a2] 

(Ax':  Tra 

n  ai.  M  [a2]  (x  (U 

[ai] 

x'))) 

M 

[V[X] 

a] 

=  Xx 

V  [x]  a.  newpid  [x]  [a 

](A 

a'  :x-  M  [ 

a  a']  (x  [a'])) 

M 

[V^a] 

=  Xx 

V^a.  newkpid  [a]  (A^x 

.  M 

[a  [xj]  (x 

[xf)) 

M 

[Id  a] 

=  Xx 

Id  a.  X 

U 

[int] 

=  Xx 

Tran  (int).  a: 

U 

[ai  ^ 

•  0:2] 

=  Xx 

Tran  (ai  ^  a2).  Ax' : 

CXi . 

U  [a2]  (rt 

ipp  [ai]  [a2]  X 

(M 

[ai] 

x')) 

u 

[V[X] 

a] 

=  Xx 

Tran  (V  [x]  a).  Aa'  :x 

•U[ 

a  a']  (rtapp  [x]  [a]  x  [a 

^1) 

u 

[V^a] 

=  Xx 

Tra  n  (V^ a) .  A^x-  U  [ct 

[xj] 

(rkapp  [a 

^]^[x]) 

u 

[Id  a] 

=  Xx 

Tran  (Id  a),  x 

We  assume  that  a  type  or  a  kind  does  not  need  to  be  transformed  in  order  to 
be  transmitted;  an  implementation  could  use  symbolic  representation  of  types 
(including  types  of  higher  kind)  to  achieve  this.  A  more  realistic  implemen¬ 
tation  would  be  based  on  a  language  with  type-erasure  semantics  (Section  4), 


^Ohori  and  Kato  define  one  primitive  for  creating  identifiers  for  both  term  and  type  abstraction. 
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where  types  of  higher  kind  are  represented  by  term-level  abstractions,  which 
could  be  marshalled  using  globally  unique  identifiers.  However  developing  the 
details  of  such  an  implementation  here  would  take  us  too  far  from  our  goal  of 
illustrating  how  the  new  constructs  of  enable  the  analysis  of  all  run-time 
values. 

3.1.2  Polymorphic  Equality.  Another  illustration  of  how  term-level  analy¬ 
sis  of  quantified  types  can  be  used  to  gain  access  to  representation  information 
is  provided  by  an  example  involving  the  comparison  of  values  of  existential 
type.  At  the  type-level  we  will  use  the  Typerec  operator  to  define  the  class  of 
types  admitting  equality  comparisons.  To  make  the  example  less  trivial  we 
extend  the  language  with  a  product  type  constructor  x  of  the  same  kind  as 
and  with  existential  types  with  type  constructor  3  of  kind  identical  to  that  of 
V,  writing  3a:  k.  r  for  3  [«;]  (Aa:  k.  r).  The  term  constructs  for  introduction  and 
elimination  of  existential  types  have  the  following  formation  rules. 

A;r  h  e  :  3[K]r  S;AhT'  :  n 
5;  A;  r  h  e  :  (Aa  S;  A,a:  k;T,x:t  a  \- e'  :  t' 

S;  A;T  \-  {a:  K  =  t'  ,  e'.r)  :  3a:  K.  T  A;  T  h  open  e  as  {a:  k,  x  :t  a)  \n  e'  :  t' 

Correspondingly  weextend  Typerec  with  a  product  branch  tx  and  an  existential 
branch  ra  which  behave  in  exactly  the  same  way  as  the  branch  and  the  rv 
branch  respectively.  We  will  use  Bool  instead  of  int. 

A  polymorphic  function  eq  comparing  two  objects  for  equality  is  not  defined 
on  values  of  function  or  polymorphic  types.  Following  Harper  and  Morrisett 
[1995],  we  can  enforce  this  restriction  statically  if  we  define  a  type  operator 
Eq  of  kind  ri  Et,  which  maps  function  and  polymorphic  types  to  the  type 
Void  =  Va:  ri.  a  (a  type  with  no  values),  and  require  the  arguments  of  eq  to  be 
of  type  Eq  T  for  some  type  t.  Thus,  given  any  type  r,  the  function  Eq  serves  to 
verify  that  a  non-equality  type  does  not  occur  insider. 

Eq(Bool)  =  Bool 
Eq  («!  ^  a2)  =  Void 
Eq(aixa2)  =  Eq  (ai)  x  Eq  (a2) 

Eq  (V  [x]  a)  =  Void 
Eq  (V^ a)  =  Void 
Eq(3[x]a)  =  3[x](Aai:x.Eq(aai)) 

The  property  is  enforced  even  on  hidden  types  in  an  existentially  typed  pack¬ 
age  by  the  reduction  rule  for  Typerec,  which  suspends  its  action  on  normal 
forms  with  variable  head.  For  instance  a  term  e  can  only  be  given  type 

Eq  (3a  :Et.a  x  a)  =  3a :  Ai.  Eq  a  x  Eq  a 

if  it  can  be  shown  that  e  is  a  pair  of  terms  of  type  Eq  r  for  some  r,  i.e.,  terms  of 
equality  type. 

The  polymorphic  equality  function  eq  is  defined  in  Figure  7  (we  use  a  letrec 
construct  derived  from  our  fix).  The  domain  type  of  the  function  is  restricted 
to  types  of  the  form  Eqr  to  ensure  that  only  values  of  types  admitting  equality 
are  compared. 
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letrec 

heq  :  Va :  £7.  :  £7.  Eq  a  — >  Eq  Bool 

=  Aa :  £7.  :  £7. 

typecase[A7 :  £7.  Eq  7  ^  Eq  a'  Bool]  a  of 
Bool  =>  Ax;  Bool. 

typecase[A7 :  £7.  Eq  7  — >  Bool]  a'  of 
Bool  ^  Ay :  Bool.  primEqBool  xy 
. . .  false 

/3l  X  /32  ^  Ax ;  Eq  f3i  X  Eq  /32 . 

typecase[A7 :  fi.  Eq  7  — »  Bool]  a'  of 
7x7  ^  AyiEq^xEq/?'. 

heq  [/3i]  [(i[]  (x.l)  (y.l)  and  heq  [[^2]  [71  (x-2)  (y-2) 
=?>...  false 

3[x]/3  ^  Ax:(3/3i:x.  Eq  (/3/3i)). 

typecase[A7 :  fi.  Eq  7  — >  Bool]  a'  of 

3[x']  7^  Ay:(37:x'.Eq  (77))' 

open  X  as  {/3i  :x,  xc:  Eq  (/3  j3\))  in 
open  y  as  (7:x',  yc:Eq  (77)) 

heq  [/37]  [/3'7]xcyc 

=►  . . . false 

in  let  eq  :  Vo :  fi.  Eq  OL  —*  Eq  Oi  —*  Bool 

=  Aa :  £7.  Ax:  Eq  a.  Ay:  Eq  a.  heq  [a]  [a]  xy 

in  . . . 


Fig.  7.  Polymorphic  equality  in  A^ 


Consider  the  following  two  packages. 

V  =  (aifi  =  Bool,  false:a) 

v'  =  (a :  ri  =  Bool  X  Bool,  (true,  true) :  a) 

Both  are  of  type  3a  :  a,  which  makes  the  invocation  eq  [3a  :  a]vv'  legal. 
But  when  the  packages  are  open,  the  types  of  the  packaged  values  turn  out  to 
be  different.  Therefore  we  need  the  auxiliary  function  heq  to  compare  values 
of  possibly  different  types  by  comparing  their  types  first.  The  function  cor¬ 
responds  to  a  matrix  on  the  types  of  the  two  arguments,  where  the  diagonal 
elements  compare  recursively  the  constituent  values,  while  the  off-diagonal 
elements  return  false  and  are  abbreviated  in  the  figure. 

The  only  interesting  case  is  that  of  values  of  an  existential  type.  Opening 
the  packages  provides  access  to  the  witness  types  Pi  and  of  the  arguments 
xandy.  As  shown  in  the  typing  rules,  the  actual  types  of  the  packaged  values, 
X  and  y,  are  obtained  by  applying  the  corresponding  type  functions  /?  and  p'  to 
the  respective  witness  types.  This  yields  a  perhaps  unexpected  semantics  of 
equality.  Consider  this  invocation  of  theeq  function,  which  evaluates  to  true: 


eq  [3a:ri.  a] 

{a:fl  =  3P:fl.p,  {p-.fl  —  Bool,  true:  Eq  /3) :  Eq  a) 
{a:fl  =  3P:fl  — >  ri./3Bool, 

(/3:ri  — >  ri  =  A7:ri.  7,  true:  Eq  (/3  Bool)) :  Eq  a). 
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At  run  time,  after  the  two  packages  are  opened,  the  cal  I  to  heq  is 

heq  [3l3-.n.(3][3l3:n^n.l3  Bool] 

{P'.fl  —  Bool,  true :  Eq  /3) 

{p-.fl  ^  =  Xj-.fl.j,  true :  Eq  {/3  Bool)). 

This  term  evaluates  to  true  even  though  the  type  arguments  are  different.  The 
reason  is  that  heq  actually  compares  the  types  of  the  values  before  hiding  the 
respective  witness  types.  T racing  the  reduction  of  this  term  to  the  recursive 
call  heq  [/3/3i]  [f3'  p[]xcyc  wefind  out  it  is  instantiated  to 

heq  [(A/3:  ri.  /3)  Bool]  [(A/3:  ^  $7.  /3  Bool)  (A7 :  $7.  7)]  true  true 

which  reduces  to  heq  [Bool]  [Bool]  true  true  and  thus  to  true. 

H  owever  this  result  is  justified,  si  nee  the  above  two  packages  of  type  3a:n.a 
will  indeed  behave  identically  in  all  contexts.  An  informal  argument  in  support 
of  this  claim  is  that  the  most  any  context  could  do  with  such  a  package  is  open 
it  and  inspect  the  type  of  its  value  using  typecase,  but  this  will  only  provide 
access  to  a  type  function  r  representing  the  inner  existential  type.  Since  the 
kind  K  of  the  domain  of  r  is  unknown  statically,  the  only  nontrivial  operation 
on  T  is  its  application  to  the  witness  type  of  the  package,  which  is  the  only 
available  type  of  kind  k.  As  we  saw  above,  this  operation  will  produce  the 
same  result  (namely  Bool)  in  both  cases.  Thus,  si  nee  the  two  arguments  toeq 
are  indistinguishable  by  Xf  contexts,  the  above  result  is  perfectly  sensible. 

3.2  Discussion 

Before  we  move  on,  it  is  worthwhile  to  take  another  look  at  the  A^  language. 
Specifically,  what  isthe  pricein  termsof  complexity  of  thetypetheory  that  can 
be  attributed  to  the  requirements  that  we  imposed? 

I  n  Section  2.3  we  saw  that  an  iterative  type  operator  is  essential  to  type¬ 
checking  many  type-directed  operations.  Even  when  the  focus  is  on  compiling 
ML,  we  still  have  to  consider  analysis  of  polymorphic  types  of  the  form  Va:f7.  r, 
and  their  ad  hoc  inclusion  in  kindf7  makes  the  latter  non-inductive.  Therefore, 
even  for  this  simple  case,  we  need  kind  polymorphism  in  an  essential  way  in 
order  to  handle  the  negative  occurrence  of  f7  in  the  domain  of  V.  I  n  turn,  kind 
polymorphism  allows  us  to  analyze  at  the  type-level  types  quantified  over  any 
kind;  hence  the  extra  expressiveness  comes  for  free.  Moreover,  adding  kind 
polymorphism  does  not  entail  any  heavy  type-theoretic  machinery— the  kind 
and  type  language  of  A“  is  a  minor  extension  (with  primitive  recursion)  of  the 
well-studied  calculus  F2;  we  use  the  basic  techniques  developed  for  F2  [Girard 
et  al.  1989]  to  prove  properties  of  our  type  language. 

The  kind  polymorphism  of  Xf  is  parametric,  i.e.,  kind  analysis  is  not  possi¬ 
ble.  This  property  prevents  in  particular  the  construction  of  non-terminating 
types  based  on  variants  of  Girard's  J  operator  using  a  kind-comparing  opera¬ 
tor  [Harper  and  Mitchell  1999]. 

For  analysis  of  quantified  types  at  the  term  level  we  have  the  new  construct 
e  and  the  corresponding  application.  This  does  not  result  in  any  additional 
complexity  at  the  type  level— although  weintroducea  new  type  constructor  vt 
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the  kind  of  this  construct  is  defined  compieteiy  by  the  originai  kind  caicuius, 
and  the  kind  and  type  caicuius  is  stiii  essentialiy  F2. 

Restricting  the  type  anaiysis  at  the  term  ievei  to  a  finite  set  of  kinds  wouid 
heip  avoid  the  term-levei  kind  abstraction.  However  even  in  this  case  we  wouid 
need  kind  abstraction  to  impiement  thetransiation  to  type-erasure  semantics, 
described  in  Section  5. 


4.  TYPE-ERASURE  SEMANTiCS 

i  n  this  section,  we  show  that  the  ianguage  A“  is  compati  bie  with  type-erasure 
semantics  [Crary  et  ai.  1998].  i  n  a  type-erasure  framework,  types  used  for  the 
purpose  of  type  anaiysis  are  represented  at  run  time  by  terms;  consequentiy 
type  annotations  have  no  run-time  significance  and  can  be  erased  before  exe¬ 
cution.  From  an  impiementor's  point  of  view,  thisframework  seemstosimpiify 
certain  phases  in  a  type- preserving  compiier;  most  notabiy,  typed  ciosure  con¬ 
version  [M inamide  et  ai.  1996].  Therefore,  accounting  for  type  erasure  is  an 
important  step  in  propagating  types  through  aii  phases  of  a  type-preserving 
compiier. 

4.1  Analyzable  Elements  at  the  Type  Level 

Foi  lowing  the  ideas  of  Crary,  Wei  rich,  and  Morrisett  [1998],  the  run-time  anal¬ 
ysis  of  types  is  replaced  by  analysis  of  terms  representing  types  (for  instance 
Pint  represents  int).  The  type  parameters  of  a  polymorphic  function  have  their 
representation  terms  passed  as  additional  term-level  parameters  of  the  func¬ 
tion;  correspondingly  for  every  type  parameter  a  there  is  a  term  parameter 
Xa  which  is  to  be  bound  to  the  term  representing  the  type  that  a  gets  bound 
to.  Since  the  type  language  must  be  kept  independent  of  the  term  language 
in  order  to  have  decidable  type  checking,  this  analysis  can  only  be  performed 
at  the  term  level.  The  term-level  operator  (now  called  repcase)  analyzes  these 
representation  terms. 

For  the  analysis  of  representation  terms  to  indeed  mirror  the  analysis  of 
types  in  A^,  it  must  hold  that  a  term  e  representing  type  t  has  e.g.,  the  value 
Rint  if  and  only  if  r  =  int.  I  n  [Crary  et  al.  1998]  this  is  achieved  by  defining  the 
representation  terms  so  that  e  represents  r  if  and  only  if  e  has  type  i?T,  where 
i?  is  a  new  type  constructor,  and  ensuring  that  the  type  i?r  is  singleton,  i.e., 
contains  exactly  one  value. 

Having  solved  the  problem  for  representing  types  of  kind  Li,  Crary,  Wei  rich, 
and  Morrisett  extend  this  solution  to  types  of  higher  kinds.  For  instance,  if 
a  is  a  type  parameter  of  kind  Li  Q.,  for  the  purpose  of  type  analysis  there 
must  be  a  way  to  obtain  a  term  representing  ar  for  every  type  t  of  kind  Li, 
given  the  terms  representing  a  and  t.  This  implies  that  the  representation 
of  a  must  be  a  term  which  defines  a  function  from  Rt  to  R  (ar);  taking  into 
account  the  requirement  for  polymorphism,  the  representation  of  a  is  of  type 
yiS-.n.Rp  ^  R{a(i).  In  the  language  of  [Crary  et  al.  1998],  which  has  no  kind 
polymorphism,  this  construction  generalizes  (by  induction  on  the  structure  of 
kinds)  to  the  following  definition  of  the  type  R^.  (t)  of  terms  representing  the 
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typer  of  kind  k,\ 

Rq  (t)  =  Rt 

Ri^^k'  {t)  =  yp-.K.  Rf,{f3)  ^  Rk' {t  f3). 

I  n  the  absence  of  kind  abstraction  and  appiication,  i?„  (r)  can  be  expanded 
staticaiiy  for  any  k.  However  in  there  are  poiymorphic  kinds  and  kind  vari- 
abies,  and  deariy  a  probiem  arises  when  k  is  a  variabie  x-  if  r  is  of  kind  x- 
since  the  ianguage  does  not  offer  kind  anaiysis,  there  is  no  way  to  find  the 
typei?^  (t)  of  the  representation  of  t,  uniess— simiiariy  totheterm-ievei  rep¬ 
resentation  of  type  variabies— the  type  operator  R^  is  provided  as  an  extra 
type-ievei  parameter  of  the  kind  abstraction  for  x-  Hence  for  every  kind 
variabie  x  the  transiation  of  a  Xf  program  to  the  type-erasure  ianguage  must 
add  a  type  variabie  which  represents  the  type  of  term-ievei  representations 
for  types  of  kind  x-  The  type  of  terms  representing  t  is  then  t;  hence  the 
kind  of  must  bex  ^ 

As  we  show  next,  however,  the  straightforward  inciusion  of  these  type-ievei 
parameters  breaks  the  inductiveness  of  in  the  type-erasure  ianguage. 

Recaii  that  the  term  transiation  introduces  a  new  term  parameter  of  type 
Rk  (a)  for  every  type  parameter  a  of  kind  k.  Thus  a  A“  term  of  type ya:  k.t 
wiii  be  transiated  to  a  term  having  a  type  of  the  form  Va  :  k.R^  (a)  ^  ■  ■. 
Therefore  the  transiation  must  aiso  change  type  annotations  of  term-ievei  pa¬ 
rameters  of  poiymorphic  type  (as  in  Ax  :  Va  :  k.  r.  •  •  •)  to  match  the  new  types 
of  the  arguments.  However,  duetothe  poiymorphism,  it  cannot  be  determined 
staticaiiy  if  a  function  wiii  be  invoked  with  an  argument  of  poiymorphic  type, 
for  instancethe  poiymorphic  identity  combinator  i  ee  Aa:fl.  Xx:a.x  is  invoked 
with  itseif  asan  argument  in  i  [Vaifi.a  ^  a]  I.  Note  further  that  it  is  infeasibie 
for  the  transiation  to  change  the  structure  of  the  type  argument  Va :  a  ^  a, 
because  it  may  beanaiyzed  by  the  function  using  Typerec. 

There  is  a  soiution:  the  transiation  can  appiy  to  the  type  annotations  inter¬ 
pretation  operators  which  map  the  A“-styie  type  arguments  to  the  types  ex¬ 
pected  after  the  transiation.  i  n  fact,  since  the  types  of  the  arguments  are  in 
generai  determined  in  type  contexts  unreiated  to  the  context  of  the  function, 
these  operators  cannot  take  advantage  of  free  type  variabies  and  must  be  the 
sameciosed  type  operator,  caii  it  F.  Soi  couid  bemappedtoAa:ri.Ax:Fa.x. 

Since  the  resuit  of  F  depends  on  the  structure  of  its  argument  (e.g.,  func¬ 
tion  types  arejust  iterated  through,  whiie  poiymorphic  types  are  transformed 
as  shown  above),  it  must  be  defined  using  type  anaiysis.  i  n  the  case  of  poiy¬ 
morphic  types,  F(V[k]t)  must  yieid  V[k]  (Aa  :  k.  (a)  ^  F(Ta)),  for  any  k. 
But  here  we  have  the  oid  probiem  again:  there  is  no  way  to  construct  for 
unknown  k. 

The  oid  soiution— add  a  parameter  providing  R^,  this  time  for  a  type-ievei 
kind  abstraction  on  x,  as  in  the  V  branch  of  Typerec— is  the  oniy  reasonabie  way 
out.  However  we  must  aiso  ensure  that  there  is  an  argument  we  can  suppiy  for 
this  parameter,  in  particuiar  when  reducing  a  Typerec  appiied  toa  poiymorphic 
type.  The  type  depends  on  the  kind  k  carried  by  the  constructor  V,  hence 
we  can  oniy  have  it  if  it  was  passed  together  with  theV  as  an  additionai  argu¬ 
ment.  So  the  poiymorphic  type  must  have  the  shape  V[k]  r,  whereV  isthe 
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(kinds)  K  ::=  Q  |  T  |  /c  — ^  k'  |  X  I 

(types)  r  ::=  int  I  ^  I  V  I  V+  I  i?  I  Tin,  |  T_  |  Tv  |  T^+  \ 

I  a  I  Ax-t  I  t[k]  I  \a:K.T  \  r  t'  \  Tagrecf/t]  r  of  (rint;  r^;  rv;  r^;  r^j) 

(values)  V  ::=  i  \  I  AaiK.e  |  Xxir.e  \  fixxir.i; 

I  Rint  I  R^  I  R^M  I  R^Mt;  I  R^[r]i;H  |  [r]  i;  [r>^ 

I  Rv  I  Rv[«f  I  Rv[«:f[r]  I  Rv[«:f  MM  I  RvM+MMI^ 

I  ^v+  I  ^v+M  I  I  I  M  I  RrMr 

(terms)  e  ::=  t?  |  x  |  e  [k]'*'  |  e  [r]  |  ee'  \  repcase[r]  eof  (ejnt;  e— *;  ev;  e^+;  e^) 

Fig.  8.  Syntaxof  the language 


polymorphic  type  constructor  in  the  type-erasure  language,  which  must  have 
kind  Vx-  (x  ^  ^  (x  ^ 

Thus  the  translation  must  replace  kind  applications  of  V;  however  V  is  a 
first-class  type  in  Xf,  so  for  instance  the  type 

(Aa :  (Vx.  (x  ^  ^  ■  a  P  (A/3 :  .  /3  ^  /?))  V 

is  well-formed.  Consequently  a  compositional  translation  must  augment  all 
kind  abstractions  and  applications  with  corresponding  type  abstractions  and 
applications,  and  (in  order  to  maintain  kind-correctness)  adjust  the  polymor¬ 
phic  kinds.  Denoting  the  translation  of  k  by  |k|,  we  need 

|Vx.k|  =  Vx- (x^  ^  |k|. 

One  can  expect  the  types  of  kind  k  ^  k'  to  be  uneventfully  translated  to  types 
of  kind  \k^  k'\  =  Iff]  ->  \k'\,  and  ri  to  be  mapped  to  ri. 

Consider  now  the  constructor  vt  of  kind  (Vx-  The  kind  of  its  image 

under  our  hypothetical  translation  is  (Vx- (x  ^  ^  which  has  a 

negative  occurrence  of  in  its  domain.  With  a  constructor  of  this  kind,  the 
kind  ri  in  the  target  language  is  not  inductive. 

As  we  just  saw,  for  each  kind  variable  we  need  the  type  operator  generating 
the  types  of  term-level  representations  of  types  of  this  variable  kind.  Note, 
however,  that  types  of  representations  are  not  analyzed— they  are  only  used 
in  annotations,  to  verify  that  the  terms  represent  the  claimed  types.  Thus 
the  result  kind  for  the  extra  type  argument  does  not  have  to  be  the  kind  of 
analyzable  types. 

This  is  the  idea  we  apply  in  our  intensional  polymorphic  lambda  calculus 
with  erasure,  A"^.  We  define  two  kinds  for  the  two  different  purposes  that 
is  being  used  for  in  AM  the  kind  of  types  of  terms,  and  the  kind  of  analyzable 
types.  I  n  A'h  we  reuse  the  name  for  the  former,  while  the  analyzable  types 
are  called  tags,  and  their  kind  is  denoted  by  T.  The  kind  is  defined  as  in 
Xf,  so  it  is  inductive;  the  kind  T  is  also  inductive,  because  in  the  kinds  of  its 
constructors  only  and  variables,  but  not  T,  occur  in  the  domains'  negative 
positions.  I  n  particular,  the  problematic  is  mapped  to  a  constructor  of 
kind  (Vx-  (x  ^  T)  T,  in  which  the  occurrence  of  n  is  acceptable,  since 
Tyf  is  a  constructor  of  T. 
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|n|  =  T  |k  ^  k'I  =  |k|  ^  |k'|  1x1  =  X  |Vx.k|  =  Vx- (x  ^  ^  hi 

Fig.  9.  Translation  of  kinds  to  A"  kinds 


£■  h  A 

S-,A\-  Rn  =  R  : 

£■;  A  h  :  X  ^  ^ 
A  h  R^  =  :  x 


£■;  A  h  R;.;  =  r  ;  |k|  ^  ft  £■;  A  h  R„/  =  r'  :  |k'|  ^  ft 

tT;  A  h  =  Ao:  |k  ^  k'|.  V/3:  |k|.  r  /?  — >  t'  (« /3) 

:  |k  — >  k'I  — >  ft 


£■, x;  A,  :x  ^  ft  k  Rre  =  T  ;  |k|  ^  ft 

£■;  A  h  Rvx.  K  =  AoiIVx-kI.V^ X-Vqx^X  ^  ft.r  (o  [x]  «x) 
:  |Vx.k|  ^  ft 


F  i  g.  10.  T ypes  of  representati  ons  at  h  i  gher  ki  nds 


The  syntax  of  isshown  in  Figures.  The  type  calculus  of  contains  types 
and  tags,  distinguished  by  their  kind;  while  types  (of  kind  fi)  classify  terms, 
tags  (of  kind  T)  are  used  for  analysis.  For  every  constructor  that  generates  a 
type  of  kind  there  is  a  corresponding  constructor  that  generates  a  tag  of  kind 
T,  e.g.,  for  int  wehaveTint,  and  for  ^  we  haveT_^.  The  type  analysis  construct 
at  the  type  level  is  Tagrec  and  it  operates  on  tags. 

At  the  term  level  we  have  representations  for  tags,  since  they  are  the  ana¬ 
lyze  ble  elements.  The  primitive  tags  have  corresponding  term-level  represen¬ 
tations;  for  example.  Tint  is  represented  by  R^t.  (All  well-formed  applications  of 
the  term-level  representation  constructors,  including  partial  applications,  are 
values.)  The  type  calculus  in  A"^  includes  a  unary  type  constructor  R  of  kind 
T  — >  ri,  which  is  used  in  the  types  of  term-level  representations.  Given  a  tag 
T  (of  kind  T),  the  term  representation  of  t  is  constructed  inductively  and  has 
type  i?T;  for  example,  Rmt,  representing  Tint,  has  type  Semantically,  as 
in  [Craryet  al.  1998],  i?T  is  interpreted  as  a  singleton  type  inhabited  only  by 
(the  equivalence  cl  ass  of)  the  term  representation  of  r. 

4.2  Static  and  Dynamic  Semantics  of  A'k 

Before  we  present  the  format!  on  rules  for  A"^  types  and  terms,  it  is  useful  to  de¬ 
fine  more  precisely  the  types  of  representation  terms  for  types  of  higher  kinds. 
Since  the  goal  is  to  represent  A“types  (all  analyzable  in  Xf),  the  definitions 
follow  the  structure  of  A“  kinds.  First,  in  Figure  9  we  have  the  inductively  de¬ 
fined  translation  of  kinds  from  A^  toA's.  Since  the  analyzable  elements  of  A's 
are  of  kind  T,  theA“  kindfi  is  mapped  to  T.  On  the  other  hand  the  polymorphic 
kindVx-K  is  translated  toVx.(x  ^  ^  |k|,  since  we  must  add  a  parameter 

for  the  types  of  representation  terms  for  types  of  ki  nd  x-  but  the  types  of  repre¬ 
sentations  are  not  analyzed,  so  the  parameter's  kind  isx  ^  Next,  Figure  10 
defines  (again  by  induction  on  Xf  kinds)  the  type  operator  R^^  of  kind  |k|  ^  n, 
mapping  types  of  kind  |k|  tothetypesof  their  term-level  representations.  Note 
that  for  every  kind  variable  x  a  corresponding  type  variable  of  kind  x  ^ 
is  introduced. 

The  formation  rules  for  constructors  for  kind  fl  in  A*^  are  as  in  X‘f,  with 
the  additional  constructor  i?;  the  rules  for  R  and  the  tags  are  displayed  in 
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Kind  formation  S'tk] 

£■  h  T 


Type  formation  £’;AI-r  :  k 


£  h  A 

£-,A\-t 

T 

£  ;A\-  R 

T 

£■ ;  A  h  Tint 

K 

£-,AhT;„t 

T 

£■;  A  h 

T  ^  K  ^ 

T  — >  K  — >  AC 

£■;  A  h  T_^ 

T  ^  T  ^  T 

£■;  A  h  ry 

Vx-  (x  ^ 

^  (x  ^  T)  ^  (x  ^  tt)  ^  ft 

£■;  A  h  Ty 

Vx-  (x^^)- 

(x  - 

.T)- 

T  ;  A  h 

(Vx-  (x  - 

f  n)  ^  T)  ^ 

£-,A\-T^ 

(Vx-  (x  ^  - 

-T)- 

T 

(Vx-  (x 

— >  n)  — > 

£-,A\-T^ 

T  ^  T 

T  ^  ft  ^ 

K 

£■;  A  h  Tagrecffc]  T  of  (Tin,;  r^;  rv;  r^;  r^)  :  k 


Term  formation  £’;A;ri-e  :  t 


£■;  A  h  T  :  T  ^  ft 

£’;A|-r  £’;A;ri-e  :  Rt' 

£-,A-,r\-  Rint  :  it  Tint  £■;  A;r  h  Eint  ;  rTint 

£■;  A;r  h  :  Rn^Q^n  (T-^)  £■;  A;r  h  :  Vai  :T.  Kai  ^  V02  :T.  R02  ^  t  (T-^  01  02) 

£-;A;rhRv  :  ftvx.  (x-e)-e  (^v)  £’;A;rhev  :V^X-VQx:X^!^- 

£■;  A;r  h  R^  :  it(vx.  n)^n  ('V)  V«:x  ^  T .  R^^n  a ->  t  {T-^  [x]  «x  «) 

£’;A;ri-R^  :  Rn^n  iT^)  £',  A;r  h  e^+  :  Va:  {^x- ix  ^  ^  V- R\fx.  n  a  ^  t  {T^+ a) 

£;A-,r\-e^  :  Va:T.Ra  ^  TjT^a) _ 

£■;  A;  r  h  repcasefr]  e  of  (fiint;  e^;  ev;  e^;  Ejj)  :  tt' 

Fig.  11.  Formation  rules  for  the  new  constructs  in  A“ 


Figure  11.  Our  intention  is  to  translate  the  constructors  of  when  used  for 
type  analysis,  to  the  constructors  of  T,  hencethe  ki  nds  of  the  constructors  are 
mapped  by  |  •  |  to  the  ki  nds  of  the  correspond!  ng  tag  constructors.  Thus  the  kind 
of  Tv  is  IVx-  (x  ->  fi)  =  Vx-  (x  ^  ^  (x  ^  T)  ^  T;  the  new  argument  of 

kind  X  can  be  used  by  the  V  branch  of  the  tag  analysis  construct  Tagrec  to 
form  types  of  representation  terms  for  types  of  kind  x- 

To  allow  analysis  of  all  tags,  Tagrec  includes  an  additional  branch  for  the  tag 
constructor  T^  corresponding  to  R. 

Figure  12  shows  the  reduction  rules  for  Tagrec,  which  are  similar  to  the  re¬ 
duction  rules  for  the  source  language's  Typerec:  givenatag,  it  calls  itself  recur¬ 
sively  on  the  components  of  the  tag  and  then  passes  the  result  of  the  recursive 
calls,  along  with  the  original  components,  to  the  corresponding  branch.  Thus 
the  reduction  rule  for  the  function  tag  is 

Tagrec[K]  (T_^tt')  of  (Tint;  t^;  ry;  Tyf;  r^) 

^  T  (Tagrec[K]  t  of  (Tint;  t_^;  ry;  t„)) 
t'  (Tagrec[K]  t'  of  (Tint;  t_^;  ry;  Tyf;  t^)). 

Similarly,  the  reduction  for  the  polymorphic  tag  is 

Tagrec[K]  (Ty  [k]  t^  t)  of  (Tint;  ry;  T^r;  t^) 

Ty  [k]  T«;  T  (Aa : K.  Tagrec[K]  (to;)  of  (Tint;  r_^;  ry;  T^r;  t^)). 

Figure  11  also  shows  the  typing  rules  for  the  term  representations  of  con¬ 
structors  of  T  and  for  the  repcase  construct.  These  rules  use  the  type  operator 
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£■;  A  h  Tagrecfft]  Tin,  of  ("Tint;  tv;  T'y+;  "Tr)  :  « 

£■;  A  h  Tagrecfre]  Tin,  of  (rin,;  tv;  t^+;  Tr)  ^  Tin,  ;  k 

£■;  A  h  Tagrecfre]  r,  of  (Tin,;  r^;  tv;  r^+;  Tr)  ^  r '  :  k 

£■;  A  h  Tagrec[K]  T2  of  (Tin,;  r^;  tv;  r^;  Tr)  ^  r '  :  k 

£■;  A  h  Tagrecfre]  (T.^  r,  T2)  of  (rin,;  r^;  tv;  t^;  Tr)  ^  r,  r{  T2T^  :  k 

£■;  A,  o:k' h  Tagrecf/t]  (t2  o)  of  (Tin,;  T^;  Tv;  T^+;  Tr)  ^  t'  :  k 
£■;  A  h  Tagrecf/t]  (Tv  [k']  ti  T2)  of  (rin,;  r^;  tv;  r^+;  Tr)  ^  rv  [k']  ri  r2  {\a-.K' .t')  :  k 

^  h  Tagrec[K]  (t  [x]  ax)  °f  ("nnt;  tv;  T^;  Tr)  ^  r'  :  k 
£■;  A  h  Tagrecfre]  (T^  r)  of  (-rint ;  t^  ;  tv;  t^;  Tr  )  ^  r  (Ax- Aa^, :  x  ^  fi.  t')  :  k 


£■;  A  h  Tag 

rec[K]  T  of  (Tint 

;  Ty;  T^;  Tr) 

r'  :  K 

S;  A  \-  Tagrec[K. 

]  ('TrT)  of  (Tint 

;  '^vi  '\'+; 

^  Tr  T  r'  :  K, 

Fig.  12.  Non-standard  reduction  rules  for  A"  types 

X-  ^ 

^{k/x} 

(fixmr.  i;)  [r] 

(flfix  rc :  r.  i;/rr})  [r] 

(Aa :  K.  e)  [r] 

e{r/Q:} 

(fixrcir.  -u) 

(i;{fix  rc :  r.  f/rc})  [k] 

(Arc  :T.e)v 

e{v/x} 

(fixrr  :r.  f)  v'  ^ 

(i;{fix x:t.v/x})  v' 

e  ^  ei 

ei 

ei 

e  ^  ei 

ee'  ei  e' 

V  V  e\ 

e  [t]  ^  Bi  [t] 

e  [k]'^  ei  [k.]'*' 

repcasefr]  Rin,  of  (ein,;  e^;  ev;  e^+;  Br)  ^  ein, 
repcase[r]  [ti]  (t;,)  [T2]  (T2)  of  (cin,;  e^;  ev;  e^;  Br)  ^  b^  [ti]  (j;,)  [t2]  {V2) 
repcase[T]  Ry  [fcf  [t,,]  [t']  (t)  of  (fiin,;  B^;  By;  6^;  Br)  ^  By  [k]’*'  [t^]  [t']  (i;) 

repcase[T]  R^+  [t']  (v)  of  (Bin,;  B^;  By;  b^+;  Br)  ^  e^+  [t']  (v) 

repcase[T]  Rr  [t']  (v)  of  (fiin,;  B^;  By;  b^;  Br)  ^  Br  [t']  (t) 

e' 

repcase[T]  b  of  (fiin,;  b^;  By;  b^;  Br)  repcase[T]  e'  of  (Bin,;  B^;  By;  B^;  Br) 

Fig.  13.  Term  reduction  rules  of  A" 


i?R  as  defined  in  Figure  10  (to  save  ink  we  are  a  bit  sloppy  with  the  notation, 
using  directly  as  a  type  instead  of  including  its  formation  in  the  premises). 
The  typing  of  repcase  can  be  derived  from  its  reduction  rules,  displayed  in  Fig¬ 
ure  13.  The  expression  being  analyzed  must  be  of  type  Rt' ,  since  repcase  an¬ 
alyzes  term  representation  of  tags.  Operationally,  it  examines  the  head  of  the 
representation,  selects  the  corresponding  branch,  and  passes  the  components 
of  the  representation  to  the  selected  branch. 
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(values)  V  ::=  i  \  Xx.e  \  f\xx.v  \  Rjnt  |  |  R^  1  |  R^lt)  |  R^lul  | 

I  Rv  I  Rvl  I  Rvll  I  Rvlll  I  Rvlll^  I  V  I  I 

I  Rh  I  RrI  I  Rr1« 

(terms)  e  ::=  v  \  x  \  ee'  \  repcase  e  of  (eint;  e— ►;  ev;  e^;  e^j) 

e  -^o  e\  e  e\ 

(\x:T.e)v'^oe{v/x}  (f\xx:T.v)  v'  (v{tixx:T.v/x})  v'  ee''^oeie'  ve'^ovei 


repcase  Rjnt  of  (eint; 

e— >,  e\y;  e^) 

'^0 

Ojnt 

repcase  R— .  1  f  1 1;'  of  (eint; 

e— > ,  e\y;  e^) 

'^0 

e^  1  f  1  f' 

repcase  Ry  1 1 1 of  (eint; 

e— *;  ev; 

'^0 

ev  1 1 1 

repcase  R^+  Itf  of  (eint; 

e— ev; 

'^0 

e^+lv 

repcase  R^^  If  of  (eint; 

e— ev;  ^v^’ 

'^0 

e^  Iv 

e  '^o  e' 

repcase  e  of  (eint;  e^;  ev;  e^;  e^j) -^orepcase  e' of  (eint;  e^;  ev;  e^;  e^ 


Fig.  14.  Syntax  and  semantics  of  the  untyped  language  A"° 


/  A+ 

(A 

O 

II 

(e  [k.]”*")  =  e'^  1 

Rint°  —  Rint 

(Aa :  K..  e)*^ 

=  A_.e^ 

(e[r])°=e-l 

R^°  =  R^ 

(Aa; :  r.  e)'^ 

=  Xx.e'^ 

(eeO°  =e°  e^° 

Rv°  =  Rv 

(fixxir. 

=  i'\xx.v'^ 

X°  =  X 

i°  =  i 

o  o 

ii  ii 

^  % 

of  (eint;  e^; 

ov;  ^v^! 

))‘^  =  repcase  e°  of  (e 

int°;  e^°;  ev° 

Fig.  15.  Translation  of  A"  to  A"° 


The  language  enjoys  the  following  properties. 

Proposition  4.1  (Type  Reduction).  Reduction  of  well-formed  types  is 
strongly  normalizing  and  confluent. 

Proposition  4.2  (Type  Safety).  If  \-  e  :  t,  then  either  e  is  a  value  or 
there  exists  a  term  e'  such  that  e'  and  \-  e'-.r. 

The  proofs  of  these  propositions  are  similar  to  the  proofs  of  the  corresponding 
propositions  for  Xf. 

4.3  The  Untyped  Language 

To  demonstrate  that  the  types  in  are  not  necessary  for  computation,  we 
present  an  untyped  language  A‘^°  in  Figure  14,  and  a  translation  from  A”^  to 
A‘^°  in  Figure  15;  the  expression  1  in  these  figures  is  the  integer  constant.  The 
untyped  language  has  the  following  property  which  shows  that  term  reduction 
in  it  parallels  the  term  reduction  in  A'r. 

Proposition  4.3.  /fe-^  ei,  than  e°  ei°. 
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Corollary  4.4.  If  \-  e-.r  ande°  '^c.eQ,thenthere&<i5t5e'  suchthat  \-  e'-.r 

and  e'°  =  e'g. 

Proof  From  h  e  :  t  by  Proposition  4.2  we  have  that  either  e  is  a  value,  or 
e  e'  for  some  e'  such  that  h  e' :  r.  Since  (by  inspection  of  the  definition  of 
values  in  Figures  13  and  14)  the  erasure  of  a  value  is  a  value,  and  if  u  is  a 
value,  then  v  '^o  ej,  for  no  e'g,  it  follows  that  e  is  not  a  value.  Thus  there  exists 
e'  such  that  e'  and  h  e'-.r.  By  Proposition  4.3,  e°  e'°.  By  induction  on 
the  structure  of  untyped  terms,  for  any  untyped  term  eo  at  most  one  derivation 
exists  deriving  Co  ei  for  someei.  Thus  from  e°  e'g  and  e°  e'°  we  have 

e'o  =  e'°.  □ 

Corollary  4.5  (Safety  of  A%°).  If  h  e-.r  and  e°  e'o  for  some  untyped 

term  cq,  then  either  ef,  is  a  value  or  there  exists  an  untyped  term  e'o  such  that 

e'o  e()'. 

Proof  By  induction  on  the  length  of  the  reduction  sequence  deriving  e° 
e'o.  If  the  length  is  zero,  by  Proposition  4.2  either  e  is  a  value,  in  which  case  its 
erasure  e°  is  a  value,  or  e  e'  for  some  e',  and  then  by  Proposition  4.3  e° 
e'°.  I  n  the  inductive  case,  assuming  the  statement  holds  for  all  sequences  of 
length  n  and  given  a  sequence  of  length  n+1,  let  the  first  step  of  the  sequence 
bee°  e'l.  Then  by  Corollary  4.4  there  exists  e'  such  that  h  e':T  and  e'°  =  e'^. 
Since  the  rest  of  the  sequence  derives  ei  eg,  the  result  follows  directly  by 
the  inductive  hypothesis  applied  toe'.  □ 

Thetranslation  replaces  type  and  kind  applications  (abstractions)  by  dummy 
applications  (abstractions),  instead  of  erasing  them.  This  peculiarity  is  due  to 
the  semantics  of  the  fix  construct  in  our  typed  languages:  A  type  or  kind  ap¬ 
plication  of  a  fixpoint  term  reduces  by  unfolding  thefixpoint.  The  translation 
inserts  the  dummy  applications  and  parameters  to  ensure  the  corresponding 
unfolding  in  the  untyped  language. 

5.  TRANSLATION  FROM  A“  TO 

In  this  section,  we  show  a  translation  from  A“  to  A*^.  The  languages  differ 
mainly  in  two  ways.  First,  the  type  calculus  in  A'j^  is  split  into  tags  and  types, 
with  types  used  solely  for  type  checking  and  tags  used  for  analysis.  Since  any 
type  argument  in  X'f  can  potentially  be  analyzed,  type  passing  in  X'f  will  be 
translated  to  tag  passing  in  A”^,  while  type  annotations  will  be  reconstructed 
from  the  tags.  Second,  the  typecase  operator  in  A^  must  be  translated  to  a 
repcase  operating  on  term  representations  of  tags. 

Figure  16  shows  thetranslation  of  A“  types  into  A'h  tags.  The  primitive  type 
constructors  are  mapped  to  the  corresponding  primitive  tag  constructors.  No¬ 
tice  all  closed  A“  types  in  normal  forms  are  translated  into  similarly  structured 
A*^  tag  types  (except  that  Ty  now  takes  an  extra  argument)— this  is  important 
since  any  nontrivial  structural  changes  may  alter  the  results  of  analysis  via 
Typerec.  The  Typerec  is  translated  to  a  Tagrec;  thetranslation  inserts  an  arbi¬ 
trarily  chosen  result  of  the  correct  kind  intothe  branch  for  theT^  tag  sincethe 
source  contains  no  such  branch. 

The  term  translation  is  shown  in  Figure  17.  Thetranslation  must  maintain 
two  invariants.  First,  for  kind  variable  x  in  scope  there  is  a  corresponding 
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|Ax-'r|  =  Ax.  |t|  |  Aq  :  k.  r|  =  A«  :  |k|.  |t|  |int|  =  rint  |V|=Tv 

|r[K]|  =  |T|[|K|]_RK  \tt'\  =  \t\\t'\  |^|=T_^  |V*j=r^ 

\a\=a 

|Typerec[K]  T  of  (Tint;  T^;  Tv;  r^+)|  =  Tagrec[|K|]  |t|  of  (Irintl;  |t^|;  |tv|;  |t^+|;  A.:T.  A.:  |k|.  |Tint|) 

F  i  g.  16.  TransI  ati  on  of  A“  types  to  A“  tags 


N  =  * 

|a;|  =  X 

lA^-el  =  A'^x- Aox^X  ^  |e| 

|eH+|  =  |e|  [|«ir[it«] 

|Aq:  :K.e\  =  Koi :  |k|.  Axa  :  /?«,  ol-  |e| 
|e[r]|  =  |e|[|r|]5R(T) 

\\x:T.e\  =  Aa; :  F  |r|.  |e| 

|ee'|  =  |e|  |e'| 

\V\xx:t.v\  =  fixx:  F  |r|.  |i;| 


|typecase[T]  r'  of  (eim;  e^;  ey;  e^)| 

=  repcase[Aa : T.  F  (|r|  a)]  of 

l^int  ^  l^intl 

^|e^| 

Rv  ^|evl 

V=^lvl 

R„  ^A/3:T.fixa;:/?/3^  F  (|t|  (T^ /3)).  Ax' : iJ/3. a; a;' 


Fig.  17.  Translation  of  A^  terms  to  A"  terms 


5R(int)  =  Rint 

5R(^)  =  Ao  :T.  Axq,  -.Ra.  A/3:T.  Xxp-.Rp.  R^  [o]  {xa)  [/3]  {xp) 

3fJ (V)  =  A"^X-  Aox  :  X  ^  A2.  Aq  :  X  ^  T.  Axa  :  (“)  •  [x]’*'  [“xl  H  ) 

5R(V*)  =  A«:  (Vx.  (X  ^  ^  T).  Xx^  -.R^^,  n  (a).  R^+  [a]  (x^) 

5R(o)  =  Xa 

5R(Ax-  t)  =  A”^ X-  Aox  :  X  ^  tl-  5R(x) 

5R(r  N)  =  5R(t)  [|K|f[7t«] 

5R(Aa:  K.  r)  =  Ao:  |k;|.  Ax^  '.Rk  ci-  5R(t) 
sR(tt')  =  5R(t)  [|t'|]  (5R(t')) 

5R(Typerec[K]  r  of  (rim;  \  ry;  t^))  = 

(fixf:Va:T.  i7o  ^  R  (t*  a). 

Aa : T.  Axq.  -.Ra. 
repcasefAo :  T.  R  (t*  «)]  Xa  of 
Rint  ^  5R(Tint) 

R^  =>  Aa:T .  Xxa'.  Ra.  A/3:T .  Xxp  :  R 

di{T^)  [o]  (xq)  [t*  o]  (f  [a\xa)  [/3]  {xp)  [t*  /3]  {i[l5\xp) 

Rv  ^A  X-A«x:x  ^  n.  Ao:x  ^  T.  Axa  :  (o). 

[xf  [ox]  H  i^a)  [A/3:x.t*  (ap)]  (Ap-.x- Xxpia^  P.f[a  P]  (x^  [P]xp)) 
Ry+  =>  Aa:(Vx.  (x  ^  F2)  ^  T).  Xx^  .R^^.n  (a). 

5R(Tyf )  [“1  (*“)  Aox  (a  [x]  ax)] 

(A’^X-Aa^iX  ^  n.f[a  [x]  o^j  (x^  [xf  KD) 

Rjj  Aa:T.  Xxa.:  Ra.^{Tint)) 


5R(r) 

where 

T*  =  I Aq  :  Q.  Typerecf/t]  o  of  (rint;  t_>  ;  Ty ;  t.^)| 


Fig.  18.  Representation  of  X‘p  types  as  A"  terms 
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type  variable  a^,  which  gives  the  type  of  the  term  representation  for  a  tag 
of  kind  X-  At  every  kind  application,  the  translation  uses  the  function 
(Figure  10)  to  compute  this  type.  {Rk  is  defined  at  the  meta-level  by  induction 
on  K,  but  for  every  k  the  result  is  a  type  in  Thus,  the  translations  of  kind 
abstractions  and  kind  applications  introduce  an  additional  type  abstraction 
and  application,  respectively. 

Second,  for  every  type  variable  a  in  scope  there  is  a  term  variable  Xa,  pro¬ 
viding  the  term  representation  of  a.  At  every  type  application,  the  translation 
uses  the  meta-function  3?  (Figure  18)  to  construct  this  representation.  Further¬ 
more,  type  application  is  replaced  by  a  type  application  to  the  tag  correspond- 
ingtothetypeargument,  followed  by  an  application  totheterm  representation 
of  this  tag. 

Programsin  pass  tags  at  run  time  si  nee  only  tags  can  be  analyzed.  Flow- 
ever,  abstractions  and  thefixpoint  construct  must  still  carry  type  annotations 
for  type  checking.  These  annotations  are  reconstructed  from  the  tags  corre¬ 
sponding  to  the  types  by  the  tag  interpretation  operator  F,  defined  within 
the  A'j^  type  language  using  Tagrec.  Si  nee  the  annotations  are  always  of  kind  n, 
this  operator  must  map  tags  of  kind  T  to  types  of  kind  fi.  In  pattern-matching 
syntax  the  operator  is  defined  as  follows: 

F(Tint)  =  int 

F  (r_^  ai  q;2)  =  F(ai)^F(a2) 

F  (Tv  [x]  Q^x  «)  =  V/3 :  X-  Q^x  /3  ^  F  {a  (3) 

F(T^a)  =  vVVax:X^f^-F(a[x]ax) 

F  (Tjj  a)  =  Ra 

The  function  F  maps  a  tag  representinga  A^  typetothecorresponding  A”^  type. 
Thus  it  maps  the  tag  Tint  to  the  type  int,  and  recursively  converts  the  compo¬ 
nents  of  other  tags  to  the  corresponding  types  before  combining  the  results 
with  constructors.  The  branch  for  the  tag  is  irrelevant,  as  long  as  it  has 
the  correct  kind,  si  nee  the  language  A'r  is  only  intended  as  a  target  for  trans¬ 
lation  from  A^— the  only  interesting  programs  in  A”^  are  the  ones  translated 
from  Xf,  in  which  theT^  branch  of  F  is  never  reached. 

The  tag  interpretation  function  F  is  another  example  of  a  type  transforma¬ 
tion  defined  within  the  type  language  instead  of  at  the  meta  level  (cf.  the  dis¬ 
cussion  in  Section  2.3). 

The  following  two  properties  hold  since  the  branches  of  F  have  no  free  type 
or  kind  variables. 

Lemma  5.1.  (F  (r)){T'/a}  =  F(T{r'/a}) 

Lemma  5.2.  (F (r)){K/x}  =  F (t{k/x}) 

We  show  the  term  representation  of  types  in  Figure  18.  The  primitive  type 
constructors  get  translated  to  the  correspond!  ng  term  representation.  The  rep¬ 
resentations  of  type  and  kind  functions  are  similar  to  the  term  translation  of 
type  and  kind  abstractions.  The  only  involved  case  is  the  term  representation 
of  a  Typerec.  Since  Typerec  is  recursive,  we  use  a  combination  of  a  repcase  and 
a  fix.  Note  that  the  translation  of  type-level  kind  polymorphism  in  Xf  requires 
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term-level  kind  polymorphism  in  e.g.,  theV  branch  of  Typerec  is  translated 
using  term-level  kind  abstraction. 

By  induction  on  the  structure  of  kinds  we  have  the  following  properties  of 
the  translation. 

Lemma  5.3.  \kW /x}\  =  \k-\{W\/x} 

Lemma  5.4.  /x'} 

I  n  the  following  propositionsthe  original  A“  kind  environment  A  is  extended 
with  a  kind  environment  A(£)  which  binds  a  type  variable  of  kind  x  ^  ^ 
for  each  x  ^  under  the  assumption  that  ^  A.  Similarly  the  term-level 
translations  extend  the  type  environment  r  with  r(A),  binding  a  variable  Xa 
of  typei?„a  for  each  type  variable  a  bound  in  A  with  kind  k. 

Proposition  5.5  (Well-formedness  of  translated  types). 
lfS;A\-T:Khdd5inXf,then\S\;\A\,A{£)h\T\  :  \k\  holds  in 

Proof  Follows  directly  by  induction  over  the  structure  of  T.  □ 

Proposition  5.6  (Types  of  representation  terms). 

/f  A  h  T  :  K  and  A  h  r  hold  in  Xf,  then  \£\;  |A|,  A(£:);  |r|,  r(A)  h  3?(t)  : 

|r|  holds  in  X‘^. 

Proof  By  induction  over  the  structure  of  t.  The  only  interesting  case  is  that 
of  a  kind  application  which  uses  Lemma  5.4.  □ 

Proposition  5.7  (Well-formedness  of  translated  terms). 

lf£;A;T  heir  holds  in  Xf,  then  \£\;  |A|,  A{£);  |r|,  r(A)  h  |e|  :  F  |t|  holds  in 

^Ik- 

Proof  By  induction  over  thestructureof  e,  using  Lemmas  5.1  and  5.2.  □ 
6.  RELATED  WORK 

The  work  of  Flarper  and  Morrisett  [1995]  introduced  intensional  type  analy¬ 
sis  and  pointed  out  the  necessity  for  type-level  type  analysis  operators  which 
inductively  traverse  the  structure  of  types.  The  domain  of  their  analysis  is  re¬ 
stricted  to  a  predicative  subset  of  the  type  language,  which  prevents  its  use  in 
programs  which  must  support  all  types  of  values,  including  polymorphic  func¬ 
tions,  closures,  and  objects.  This  paper  builds  on  their  work  by  extending  type 
analysis  to  include  the  full  type  language. 

Crary  and  Wei  rich  [1999]  propose  a  very  powerful  type  analysis  framework. 
They  define  a  rich  kind  calculus  that  includes  sum  kinds  and  inductive  kinds. 
They  also  provide  primitive  recursion  at  the  type  level.  Therefore,  they  can 
define  new  kinds  within  their  calculus  and  directly  encode  type  analysis  oper¬ 
ators  within  their  language.  They  also  include  a  novel  refinement  operation  at 
the  term  level.  Flowever,  their  type  analysis  is  "limited  to  parametrically  poly¬ 
morphic  functions,  and  cannot  account  for  functions  that  perform  intensional 
type  analysis"  [Crary  and  Weirich  1999,  Section  4.1].  Our  type  analysis  can 
also  handle  polymorphic  functions  that  analyze  the  quantified  type  variable. 
Moreover,  their  type  analysis  is  not  fully  reflexive  since  they  can  not  handle 
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arbitrary  quantified  types;  quantification  must  be  restricted  to  type  variables 
of  kind  fl. 

Duggan  [1998]  proposes  another  framework  for  intensional  type  analysis; 
however,  he  allows  the  analysis  of  types  only  at  the  term  level  but  not  at  the 
type  level.  Yang  [1998]  presents  some  approaches  to  enable  type-safe  program¬ 
ming  of  type-indexed  values  in  ML  which  is  similar  to  term-level  analysis  of 
types.  Having  term-level  analysis  only  is  not  enough  for  applications  such  as 
type  safe  garbage  collectors  [Monnier  et  al.  2001]  (where  type-level  analysis  is 
used  to  certify  the  memory  interface  between  the  mutator  and  the  collector). 

Necula  [1998]  proposed  the  ideas  of  a  certifying  compiler  and  implemented 
a  certifying  compiler  for  a  type-safe  subset  of  C.  Morrisett  et  al.  [1998]  showed 
that  a  fully  type-preserving  compiler  generating  type-safe  assembly  code  is  a 
practical  basis  for  a  certifying  compiler. 

The  idea  of  programming  with  iterators  is  explained  by  Pierce  et  al.  [1989]. 
Pfenning  and  Paulin-Mohring  [1989]  show  how  inductively  defined  types  can 
be  represented  by  closed  types.  They  also  construct  representations  of  all  prim¬ 
itive  recursive  functions  over  inductively  defined  types. 

Despeyroux  et  al.  [1997]  proposed  a  technique  for  performing  primitive  re¬ 
cursion  on  higher-order  abstract  syntax  in  a  logic  framework.  While  there 
are  some  similarities  on  the  surface,  there  are  also  many  subtle  differences 
between  their  systems  and  ours.  I  n  their  system,  there  is  a  clear  distinction 
between  theobject  language  (the  logicthey  are  representing)  and  the  meta  lan¬ 
guage  (the  underlying  logic  framework)  so  that  the  adequacy  (for  the  represen¬ 
tation)  can  be  established.  Our  system,  however,  are  not  trying  to  representing 
one  language  inside  another;  instead,  our  calculus  is  just  a  typed  intermediate 
language.  Despeyroux  et  al.  use  modal  logic  to  clearly  identify  the  set  of  terms 
that  can  be  analyzed,  while  we  use  kind  polymorphism  to  achieve  parametric- 
ity.  Their  method  does  not  apply  in  our  context  because  it  can  only  analyze 
fully  closed  terms.  Our  technique,  on  the  other  hand,  does  support  intensional 
analysis  on  types  with  free  variables. 

The  type  erasure  semantics  follows  the  idea  proposed  in  Crary  et  al.  [1998]. 
However,  they  consider  a  language  that  analyzes  only  first  order  types.  Ex¬ 
tending  the  analysis  to  arbitrary  types  makes  the  translation  into  a  type  era- 
suresemantics  much  more  complicated.  The  splitting  of  the  type  calculus  into 
types  and  tags  and  defining  an  interpretation  function  to  map  between  the 
two  are  related  to  the  ideas  proposed  by  Crary  and  Weirich  for  the  language 
LX  [Crary  and  Weirich  1999]. 

The  erasure  framework  also  resembles  the  dictionary  passing  style  in  Haskell 
[Peterson  and  ]  ones  1993].  The  term  representation  of  a  type  may  be  viewed 
as  the  dictionary  corresponding  to  the  type.  However,  the  authors  consider 
dictionary  passing  in  an  untyped  calculus;  moreover,  they  do  not  consider  the 
intensional  analysis  of  types.  Dubois  et  al.  [1995]  also  pass  explicit  type  rep¬ 
resentations  in  their  extensional  polymorphism  scheme.  However,  they  do  not 
provide  a  mechanism  for  connecting  a  type  to  its  representation.  M  inamide's 
type-lifting  procedure  [M inamide  1997]  is  also  related  to  our  work.  His  pro¬ 
cedure  maintains  interrelated  constraints  between  type  parameters;  however, 
his  language  does  not  support  intensional  type  analysis.  Weirich  [2000]  pre- 
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sented  a  technique  for  encoding  intensional  analysis  of  (non-quantified)  types 
using  Haskell  type  classes,  but  her  scheme  only  supports  term-level  analysis. 

7.  CONCLUSIONS 

We  presented  a  type-theoretic  framework  for  analyzing  quantified  (such  as 
polymorphic  and  existential)  types.  It  makes  possible  the  analysis  of  arbi¬ 
trary  quantified  types  both  at  the  type  level  and  at  the  term  level.  The  central 
idea  is  to  use  higher-order  abstract  syntax  to  represent  quantified  types,  and 
to  introduce  parametric  kind  polymorphism  to  retain  inductiveness  of  the  an- 
alyzable  kind.  The  analysis  is  not  restricted  to  parametric  quantified  type;  it 
can  also  handle  types  that  analyze  the  quantified  type  variable.  The  calculus 
A“  is  sound  and  its  type  checking  remains  decidable. 

Wealsogaveatranslation  of  our  calculus  to  a  languageA'j^  with  type-erasure 
semantics,  which  is  more  suitable  for  implementation  due  to  the  elimination 
of  run-time  significance  of  types;  the  latter  point  is  made  clear  by  establishing 
a  correspondence  with  the  reductions  in  an  untyped  language. 

For  completeness  of  the  type  analysis  and  for  the  purpose  of  this  translation 
both  Xf  and  introduce  kind  abstraction  and  application  at  the  term  level, 
and  a  correspond!  ng  type  constructor  vt  This  does  not  increase  the  complexity 
of  the  type  languages,  which  are  essentially  F2  with  primitive  recursion.  The 
termlanguagesbecomeextensionsofGirard'sAfJ  calculus  [Girard  1972],  hence 
not  strongly  normalizing;  however  strong  normalization  is  not  a  requirement 
for  a  term- level  language,  and  our  term  languages  already  includes  the  general 
recursion  construct  fix,  necessary  in  a  realistic  programming  language. 

APPENDIX 

A.  PROPERTIES  OF  Xf 

A.1  Soundness  of  the  Xf  Type  System 

The  rules  for  single-step  reduction  in  A^  are  shown  in  Figures,  and  are  stan¬ 
dard  except  for  those  involving  the  typecase  construct.  The  typecase  chooses 
a  branch  depending  on  the  head  constructor  of  the  type  being  analyzed  and 
passes  to  it  as  arguments  the  subterms  of  the  type.  For  example,  while  ana¬ 
lyzing  the  polymorphic  type  V[k]  r,  it  applies  the  V  branch  (ey  in  the  figure)  to 
the  kind  k  and  the  type  function  r.  The  last  rule  ensures  that  the  type  being 
analyzed  is  first  reduced  to  its  unique  normal  form  (Theorem  A. 48). 

We  prove  soundness  of  the  system  using  contextual  semantics  in  the  style 
of  Wright  and  Felleisen  [1994].  The  reduction  rules  for  the  redexes  r  are  as 
shown  in  Figure  6,  and  we  define  evaluation  contexts  E  in  Figure  19.  We 
assume  unique  variable  names.  The  notation  h  e  :  r  is  used  a  shorthand  for 

e;  e;  £  I-  e:T. 

Si  nee  the  reduction  of  typecase  in  Xf  depends  on  the  form  of  a  type,  we  intro¬ 
duce  normal  forms:/  of  types  in  Figure  20. 

Lemma  A.l.  Ife;e  \-  v  :  fl,  then  v  isoneof  lnt,  V2,  V[k]  vi,  orxtvx. 

Proof  Since  v  is  well-formed  in  an  empty  environment,  it  does  not  contain 
any  free  type  or  kind  variables.  Therefore  v  can  not  be  a  iy°  since  the  head  of 
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(value)  V  ::=  i  \  A^x-^  I  Ao:K.e  |  \x:T.e  \  f'lxxir.v 

(context)  E  ::=  []  \  E  e  \  v  E  \  E  [r]  \  -B  [fc]'*' 

(redex)  r  ::=  (A^x- I  (Aq:k.  e)[T]  |  (\x:T.e)v 

I  (fixx : T.  ij)  [k]'*'  I  (f\xx:T.v)  [t']  \  (f\xx:T.v)v' 

I  typecase[r]  r'  of  (eim;  e^;  ey;  e^+) 

I  typecase[r]  int  of  (eint;  e^;  ey;  e^)  |  typecase[r]  (r  ^  t')  of  (eint;  e^;  ey;  e^) 

I  typecase[r]  (V  [k]  r)  of  (eim;  e^;  ey;  e^)  |  typecase[r]  (vV)  of  (ein,;  e^;  ey;  e^) 

Fig.  19.  Term  contexts 

::=  a  \  u  \  [k]  |  Typerecf/t]  1/°  of  i/y;  v^) 

V  ::=  I  int  I  ^  I  (^)  ly  \  (-^)  u  u'  |  V  |  V  [k]  |  V  [k]  |  | 

I  Xa :  K.  V,  where  Vf®.  u  ^  a  OC  «  £  ftv(u^) 

I  Ax.  ly,  where u  ^  [x]  or  x  e  fkv(u’^) 

Fig.  20.  Normai  forms  in  the  A"  typeianguage 


a  is  a  type  variable.  The  lemma  now  follows  by  inspecting  the  remaining 
possibilities  for  I/.  □ 

Lemma  A. 2  (Decomposition  of  terms).  If  \-  e-.r,  then  either  e  isa  value 
or  it  can  be  decomposed  into  unique  E  and  r  such  that  e  =  E{r}. 

This  is  proved  by  induction  over  the  derivation  of  h  e-.r,  using  Lemma  A.l 
i  n  the  case  of  the  typecase  construct. 

Corollary  A. 3  (Progress).  If  h  e  :  t,  then  either  e  is  a  value  or  there 
exists  an  e'  such  that  e  ^  E . 

Proof  By  Lemma  A. 2,  we  know  that  if  h  e:T  and  e  is  not  a  value,  then  there 
exist  someT;  and  redex  ei  such  that  e  =  T;{ei}.  Sinceci  is  a  redex,  there  exists 
a  contraction  62  such  that  ei  ^  62.  Therefore  E  for  E  =  E{e2}.  □ 

Lemma  A. 4.  If  \-  E{e}:T,  then  thereexistsa  E  such  that  \-  e-.E,  and  for  all 
E  such  that  \-  E:E  we  have  L  E{E}:t. 

Proof  The  proof  is  by  induction  on  the  derivation  of  L  E{e}:T.  The  different 
forms  of  E  are  handled  similarly;  we  will  show  only  one  case  here. 

—cases  =  Sici:  We  have  that  h  {Ei{e})ei  :  t.  By  the  typing  rules,  this 
implies  that  h  Ei{e}:Ti  r,  for  somen.  By  induction,  there  exists  a  E  such 
that  'r  e-.E  and  for  all  E  such  that  h  E  E,  we  have  that  h  Ei{E}  :  Ti  ^  T. 
Therefore!- (Si {e'})  ei:T.  □ 

As  usual,  the  proof  of  soundness  depends  on  several  substitution  lemmas; 
these  are  shown  below.  The  proofs  are  fairly  straightforward  and  proceed  by 
induction  on  the  derivation  of  the  judgments.  The  notion  of  substitution  is 
extended  to  envi  ronments  i  n  the  usual  way. 

Lemma  A. 5.  /f£,x  L  k  andf  h  k',  than  £  h  k{k7x}- 
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Lemma  A. 6.  If£,x;^  \~  t  :  k  and  £  h  k',  then  £;/^{k'/x}  t{k' /x}  ■ 

i^W/x}- 

Lemma  A. 7.  lf£,x;A;T  \-  e  :  t  and  £  h  k,  then  £-,I\{k/x}'-,£{k/x}  I" 
e{K/x}  :  t{kIx}- 

Lemma  A. 8.  lf£;A,a:K'\-T  :  Kand£;A\-T'  :  k',  then  £;A  h  t{t' /a}  :  k. 

Lemma  A. 9.  lf£;A,a:K;T  h  e  :  r  and  £;A  h  t'  :  k,  then  £;  A]T{t' / a}  h 
e{T' /a\  :  t{t' /a\. 

Proof  We  prove  this  by  induction  on  the  structure  of  e.  We  demonstrate  the 
proof  here  only  for  a  few  cases;  the  rest  fol  low  analogously. 

— case  e  =  ei  [ti]:  We  have  that  A  h  r'  :  k.  and  also  that  5;  A,  a  :  k;  r  h 
ei  [ti]  :  T.  By  the  typing  rule  for  a  type  application  we  get  that  5;  A,  a:  «;;r  h 
ei  :  V/3  :  K1.T2,  A,q;  :  K  I-  Ti  :  ki,  and  r  =  r2{Ti//3}.  By  induction  on  ei, 
5;  A;  r{r'/a}  h  Cilr'/a}  :  V/3:  ki.  r2{r'/Q;}.  By  Lemma  A.8,  A  h  rilr'/o;}  : 

Ki.  Therefore 

£]A\V{t' /a}'^  {ei{T' /a])[Ti{T' /a}]  :  {t2{t' / a}){Ti{T' / a] / (}}■ 

But  this  is  equivalent  to 

£\A]Y{t' /a}'^  {ei{T' /a})[Ti{T' /a}]  :  / a] . 

— casee  =  ei  [nif:  We  have  that  £;A,a:K;T\-  a  [nif  :  T  and£;  A  h  t'  :  k.  By 
the  typing  rule  for  kind  application,  5;  A,  Q;:K;r  I-  ei  :  Vx-n,  r  =  ti{ki/x}, 
and  £  h  ki.  By  induction  on  ei,  5;A;r  I-  eilr'/a}  :  \/x-ti{t' /a}.  Therefore 
5;  A;r  h  (eilr'/a})  [Kif  :  (ri{T7Q;}){«;i/x}- Since  x  does  not  occur  free  in  t' 
we  have  /a}){Ki/x}  =  (nl'^i/xDI'r'/a}- 
—casee  =  typecase[To]  n  of  (cint;  e^;  ey;  e^f):  We  have  that  5;  A  h  t'  :  K  and 
5;  A, a: k; r  h  typecase[ro]  Ti  of  (cint;  e^;  ey;  Cyf)  :  tqTi.  Using  Lemma  A. 8  on 
the  kind  derivation  of  tq  and  n,  and  the  inductive  assumption  on  the  typing 
rules  for  the  subterms  we  get 

£]A\-  T[){t' /a]  :  £t  ^  £t 
£\A\-  ti{t' /a}  :  £l 

A;r{r7a}  L  eintlr'/a}  :  (roint){r7a} 

A;  r{r7Q:}  h  e^{r7a}  :  (Vai :  Li.  Va2  :  Li.  tq  (ai  ^  a2)){T7a} 
A;r{r7a}  h  ey{T7a}  :  (V^x- Va: X  ^  t-o  (V  [x]  a)){T7a} 

£\  A-,V {t' / a}  Y  e^{T' / a}  :  (Va :  Vx- tq  (V^a)){r7a} 

The  above  typing  judgments  are  equivalent  to 

A  h  ro{T7Q;}  ■ 

£\A\-  ti{t7q;}  :  Li 

A;r{r7a}  L  eint{T7Q!}  :  (ro{T7Q;})  int 

A;  r{r7Q!}  h  e^{T7a}  :  Vai :  Li.  Va2  :  Li- (to{t7q!})  (ai  ^  a2) 

A;r{T7a}  L  ey{T7a}  :  V^x- Va:x  ^  Li.  (To{r7a})  (V  [x]  a) 

A;  r{T7Q!}  h  eyf{T7Q;}  :  Va :  Vx- Li.  (to{t7q!})  (V^a) 

from  which  the  statement  of  the  lemma  follows  directly.  □ 
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Lemma  A. 10.  If  £;A;T,x  :  r'  I-  e  :  r  and  £;A;T  h  e'  :  t',  then  £;A;T  h 
e{e' /x}  :  t. 

Proof  Proved  by  induction  over  the  structure  of  e.  The  different  cases  are 
proved  similarly.  We  will  showonly  two  cases  here. 

—case  e  =  Aa  :  K.  ei :  We  have  that  5;  A;  r,  x  :  r'  h  Aa  :  k.  ei  :  Va  :  k.  r  and 
5;  A;r  h  e'  :  r'.  Sincee  can  always  be  alpha-converted,  we  assume  that  a  is 
not  previously  defined  in  A.  This  implies^;  A,Q;:K;r,x:r'  I-  d  :  r.  Sincea 
is  not  free  in  e',  we  have  £;  A,a :  K;r  I- e'  :  t'.  By  induction,  5;  A,  a :  k;  T  h 

ei{e'/x}  :  r.  H  ence  £;  A;  T  h  Aa :  k.  ei{e'/x}  :  VaiK.r. 

— case  e  =  typecase[To]  n  of  (cint;  e^;  ey;  e^f):  We  have  that  5;  A;r  h  e'  :  t' 
and  A;  r,  X  :  r'  h  typecase[ro]  n  of  (cint;  e^;  ey;  e^f)  :  Ton.  By  the  typecase 

typing  rule  we  get 

5;  A  h  To  :  and 

A  h  Ti  :  and 
f ;  A;  r,  x:t' h  Cint  :  tq  int  and 
A;  r,  X :  r'  h  :  Vai :  fl.  Va2  -fl-To  {ai  0:2)  and 
£;  A;  r,  x:t'  h  ey  :  N/'x- Va:x  ^  Q,.  tq  (V  [x]  a)  and 
£\  A;  r,  x:t'  h  e^f  :  Va:Vx.  tq  (V^a) 

Applying  the  inductive  hypothesis  to  each  of  the  subterms  eint,e^,ey,eyf 
yields  directly  the  claim.  □ 

Definition  A. 11.  e  evaluates  toe' (written  e  1-^  e')  if  there  exist  S,  ei,  and 
e2  such  that  e  =  T^{ei}  and  e'  =  T^{e2}  and  ei  e2. 

Theorem  A. 12  (Subj  ect  reduction).  If\-  e-.r  and  ei-^  e',then\-  e'-.r. 

Proof  By  Lemma  A. 2,  e  can  be  decomposed  into  uniques  and  unique  redex 
ei  such  that  e  =  S{ei}.  By  definition,  e'  =  S{e2}  and  ei  e2.  By  Lemma  A.4, 
there  exists  a  r' such  that  l-ei:r'.  Bythesame  lemma,  all  we  need  to  prove  is 
that  h  e2 :  r'  holds.  This  is  proved  by  considering  each  possible  redex  in  turn. 
We  will  show  only  two  cases,  the  rest  follow  similarly. 

— case  ei  =  (fixx:Ti.  x)  v':  Then  62  =  (x{fixx:ri.  x/x})  x'.  We  have  that  h  (fixx: 
n.x)  x' :  t'.  By  the  typing  rules  for  term  application  we  get  that  for  some 
t2,  h  fixx  :  Ti.  X :  t2  ^  t'  and  h  x' :  t2.  By  the  typing  rule  for  fix  we  get  that, 
h  n  =  t2  r'  and  s-,£;£,x:t2  ^  t'  \-  v  :  t2  r'.  Using  Lemma  A. 10  and 
the  typing  rule  for  application,  we  obtain  the  desired  judgment  h  (x{fixx  : 
Ti.x/x})  x':r'. 

—case  ei  =  typecase[To]  n  of  (cint;  e^;  ey;  e^f):  If  n  is  not  in  normal  form,  the 
reduction  is  to  62  =  typecase[ro]  vi  of  (cint;  e^;  ey;  e^f),  where  e;£  h  ti  i— vi : 
Q..  The  latter  implies  £;e  I-  Ton  =  tq n  :  £i,  hence  h  62 :  t'  follows  directly 
from  h  ei  :t'. 

If  n  is  in  normal  form  n,  by  the  second  premise  of  the  typing  rule  for  typecase 
and  Lemma  A.l  we  have  four  cases  for  vi.  \  n  each  case  the  contraction  has 
the  desi  red  type  n  n ,  accord!  ng  to  the  correspond!  ng  premi  ses  of  the  typecase 
typing  rule  and  the  rules  for  type  and  kind  applications.  □ 
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m 

(Aq;  :  K,.  r)  r' 

t{i 

-'/«} 

m 

(Ax.  r)  [k] 

^  T{h 

Px} 

im) 

Xa :  K.  [t  a.)  r 

a  ^  ftvij) 

(m) 

Ax-(r[x])  - 

r 

X  ^ 

(ti) 

Typerec[/^] 

intof  (Tint; 

r.^;rv;r^)  -- 

^  Tint 

(t2)  ■ 

Typerec[K]  (r  — ^ 

T')of  (Tint; 

r.^;ry;r^)  - 

T— ► 

T  (Typerec [k.]  r of  (rint;  \Txf\i 

V)) 

t'  (Typerec  [k]  r'  of  (rint ;  r^ ;  ry 

;  v)) 

(*3) 

Typerec[K]  (V  [k] 

r) of  (rint; 

r.^;rv;r^)  -- 

^  rv[, 

k:]  r  (Aq:  :  k.. Typerec [k.]  (r  o:)  of  (t 

int;r.^;ry;r^)) 

(*4) 

Typerec[K]{V  r)of  (rim; 

r.^;rv;r^)  ^ 

^  V 

r  (Ax-  Typerec[K]  (r  [x])  of  (Tnt 

;r^;ry;r^)) 

Fig.  21.  Type  reductions 


A.2  Strong  Normalization  in  the  Xf  Type  Language 

Notation.  I  n  this  section  we  occasionally  write  Typerecl^]  r  of  (f)  instead  of 
Typerec[K]  t  of  (rint;  ry;  t^).  We  use  A  to  denote  a  sequence  {Ai, A^}, 
and  B{A/a}  for  the  result  of  applying  a  sequence  of  substitutions. 

The  single-step  reduction  relation  ^  on  types  is  the  union  of  the  relations 
defined  by  the  rules  in  Figure  21. 

Lemma  A. 13.  /f ti  ^  t2,  then  ti{t/q;}  ^  r2{T/a}. 

Proof  Consider  the  possiblereductionsfromri  tOT2. 
case Pi'.  I  n  this  case,  n  =  (A/3 :  k. t')  t"  and  t2  =  t'{t" /p},  for  some t', r",  and 
P,  and  without  loss  of  generality  p  can  be  assumed  not  to  occur  free  in  r.  This 
implies  that 

ri{r/a}  =  (A/3:k.  (r'lr/a}))  (T"{T/a}) 

The  right-hand  side  reduces  by  Pi  to  (r'{T/a}){T"{T/a}//3}.  Since  p  does  not 
occur  free  in  r,  this  type  is  equivalent  to  /P}){t/ a}. 

case  ^2:  In  this  case,  n  =  (Ax- t')[k]  and  t2  =  t'{k/x}-  Hence  rijr/a}  = 
(Ax.t'{t/q;})  [k],  which  reduces  by/32  to {T'{T/a}){K/x}  =  ir'{K/x}){T/a}. 
case?7i:  We  have  that  n  =  xp-.n.  {t'  p),  t2  =  r',  and  p  does  not  occur  free  in  t' 
and  T.  Hencerilr/a}  =  xp-.n.  ((r'lr/a})  /3).  Since /3  Still  does  not  occur  free  in 
r'{r/a},  this  type  reduces  by  r^i  to  r'{r/a}. 

case  772:  I  n  this  case,  n  =  Ax-  r'  [x],  r2  =  r',  and  x  does  not  occur  free  in  r' 
and  r.  Weget  that  ri{r/a}  =  Ax- (r'{r/a})  [x].  Since  X  does  not  occur  free  in 
r'{r/a},  by  7/2  this  type  reduces  to  r'{r/a}. 

The  cases  of  reductions  of  Typerec  are  similar;  we  show  only 

case  33:  ri  =  Typerec[«:]  (V  [k']  r')  of  (ript;  r_^;  ry;  r^f)  and 

t-2  =  ry  [k']  t'  (A/3:  k'.  Typerec[K]  (r'  /3)  of  (rint;  r_^;  ry;  r^^)) 

We  get  that 

ri{r/a}  =  Typerec[K]  (V  [k']  r'{r/a})  of  (rint{r/a};  r_^{r/a};  ry{r/a};  ryf{r/a}) 

This  reduces  by  to 

ry{r/a}  [k']  (r'{r/a}) 

(A/3:7t'.Typerec[7t]  ((r'{r/a})  /3)  of  (ript{r/a};  r_^{r/a};  ry{r/a};  ryf{r/a})) 

which  is  syntactically  equivalent  to  r2{r/a}.  □ 
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Lemma  A.  14.  /f ti  ^  t2,  t/ian  ti{k'/x'} t2{«;'/x^}- 

Proof  By  case  analysis  of  the  type  reduction  relation. 

case/3i:  In  this  case,  n  =  {\13:k.t')t"  andT2  =  t'{t"  /  (3}.  This  implies  that 

TiWU}  =  /^})  /'{k'/x'}, 

which  reduces  by /3i  to  {t' {k' /x'}){t" W lx'} !  1^}^  which  in  turn  is  equivalent  to 

{r'W'/m^'lx'}- 

case/32:  I  n  this  case,  n  =  (Ax-  r')  [k]  and  t2  =  t'{k/x}-  Then 

TiW /x'}  =  {^X-t'W /x!})  [«:{«7x'}], 

which  reduces  by  P2  to  t'{k'/x'}{i^W/x'}/x}-  Since  w.l.o.g.  x  is  not  free  in 
the  latter  is  equivalent  to  (t'{k/x}){k'/x'}- 
The  other  cases  follow  similarly.  □ 

Definition  A. 15.  A  typer  is  strong/ynorma/Zzab/e if  every  reduction  se¬ 
quence  from  T  terminates  into  a  normal  form  (with  no  redexes).  We  use  ^(r)  to 
denote  the  length  of  the  largest  reduction  sequence  from  r  to  a  normal  form. 

Definition  A. 16.  We  define  neutra/ types,  n,  as 

no  ::=  Ay.  r  |  Xa-.n.T 

n  ::=  a  I  noT  I  nr  I  no  [n]  |  n  [k]  |  Typerec[«;]  r  of  (Tint;  tv;  r^f) 

Definition  A. 17.  A  redudbility  candidate  (also  referred  to  as  simply  a 
candidate)  of  kind  k  is  a  set  C  of  types  of  kind  k  such  that 

(1)  if  r  e  C,  then  r  is  strongly  normalizable. 

(2)  if  r  G  C  and  r  r',  then  r'  g  C. 

(3)  if  T  is  neutral  and  if  for  all  r'  such  that  r  ^  r',  we  have  that  r'  g  C,  then 

T  €  C. 

This  implies  that  the  candidates  are  never  empty  since  if  a  has  kind  n,  then 
a  belongs  to  candidates  of  kind  k. 

Definition  A. 18.  Let  k  be  an  arbitrary  kind.  Let  Cint  be  a  candidate  of 
kind  K,  C-^  be  a  candidate  of  kind  rz  ^  n  rz  ->  n  k,  Cv  be  a  candidate  of 
kind  Vx-  (x  ^  LZ)  ^  (x  ^  ^  and  be  a  candidate  of  kind  (Vx-LZ)  ^ 

(Vx-  k)  K.  The  set  Rq  of  types  of  kind  is  then  defined  as 

{r  I  for  ail  Tint  G  Cint,  G  Cv,  and  g  C^, 

Typerec[K]  t  of  (Tint;  t_^;  ry;  t^)  G  C«;}. 

Lemma  A. 19.  Rq  is  a  candidate  of  kind  fl. 

Proof  We  will  prove  satisfies  the  requirements  of  Definition  A. 17.  In 
each  of  the  cases  below,  let  Co,  C^,  Cy,  and  Cyf  be  candidates  of  kinds  k,  ^ 
K  ^  ^  K  ^  K,  Vx-  (x  ^  fZ)  ^  (x  and  (Vx-  fi)  (Vx-  k)  k, 

respectively,  and  Tint,  ry,  and  be  elements  of  the  respective  candidates. 

(1)  Suppose  that  t  is  in  i?a,  and  let  ti  =  Typerec[K]  t  of  (T).  By  Definition  A. 18 
Ti  belongs  toCo.  By  property  1  of  Definition  A. 17,  t'  is  strongly  normaliz¬ 
able,  therefore  T  is  strongly  normalizable. 
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(2)  Suppose  T  t',  and  again  let  n  =  Typerec[K]  t  of  (r).  Then  we  have  that 
Ti  ^  Typerec[«;]  r'  of  (f).  Since  n  e  Co,  by  property  2  of  Definition  A. 17 
Typerec[K]  t'  of  (f)  belongs  to  Co-  Therefore,  by  Definition  A. 18,  t'  G  Rii- 

(3)  Suppose  T  is  neutral,  and  for  all  r',  if  t  ^  t',  then  r'  g  Let  n  = 

Typerec[K]  r  of  (f).  Note  that,  since  by  assumption  ript,  r_^,  ry,  and 
are  members  of  the  appropriate  candidates,  by  Definition  A.18  this  implies 
that  Typerec[K]  t'  of  (t)  g  Cq.  Furthermore,  the  four  branches  are  strongly 
normalizable,  hence  we  can  proceed  by  induction  on  the  length  of  ti  defined 
by  len{Ti)  =  to  prove  that  n  always  reduces 

to  a  type  that  belongs  to  Co . 

—len{Ti)  =  0.  Then  n  Typerecf^]  t'  of  (f)  is  the  only  possible  reduction 
si  nee  r  is  neutral. 

—len{Ti)  =  k  +  1.  In  this  case  the  inductive  hypothesis  is  that  any  type  of 
the  form  Typerec[K]  r  of  (f)  of  length  k  reduces  to  a  type  that  belongs  to 
Co-  Now  Ti  can  either  reduce  to  Typerec[«:]  t'  of  (f),  which  (we  showed)  is 
in  Co,  or  to 

Typerecl^t]  r  of  r_^  ;  Ty;  Tyf),  when  Tint  ^ 

Typereef^]  r  of  (Tint;  tU;  Ty;  Tyf),  when 
Typereej/t]  t  of  (rint;  t_^;  t^;  Tyf),  when  ry  Ty,  or 
Typerec[tt]  r  of  (rint;  t_^;  ry;  t^),  when  ^  t^. 

By  property  2  of  Definition  A. 17,  each  of  T|(,j,  r(„  and  also  belongs 

to  the  appropriate  candidate,  and  the  length  of  each  of  the  reducts  is  k. 
Therefore,  by  the  inductive  hypothesis,  each  of  the  reducts  belongs  toCo- 
Therefore  Typerec[K]  rof  (r)  always  reduces  to  a  type  that  belongs  toCo-  By 
property  3  of  Definition  A. 17,  Typerec[K]  r  of  (f)  also  belongs  to  Co-  Hence 
T  G  R(i-  □ 

Definition  A. 20.  Let  Ci  and  C2  be  two  candidates  of  kinds  ki  and  k2.  We 
then  define  the  set  Ci  C2,  of  types  of  kind  ki  k2,  as  {t  |  for  all  ti  g  Ci, 
TTl  G  C2}. 

Lemma  A. 21.  IfCi  and  C2  are  candidates  of  kinds  ni  and  k2,  then  Ci  ^  C2 
is  a  candidate  of  kind  ki  ^  k2- 

Proof  Wewill  proveCi  ^  C2  satisfies  the  requirements  of  Definition  A. 17. 

(1)  Suppose  T  of  kind  ki  k2  is  in  Ci  C2.  By  definition,  if  t'  g  Ci,  then 
tt'  G  C2.  Since C2  is  a  candidate,  tt'  is  strongly  normalizable.  Therefore, 
T  must  be  strongly  normalizable  since  for  every  sequence  of  reductions 
T  -vy  Ti . . .  Tfe  . . .,  there  is  a  corresponding  sequence  of  reductions  r  t'  ^ 

Ti  r' . .  .  Tfe  r' . .  .. 

(2)  Suppose  T  of  kind  ki  k2  belongs  toCi  ^  C2,  and  t-^  t'.  Let  n  g  Ci;  then 
by  Definition  A. 20  TTl  e  C2.  Butrri^r'Ti.  By  Definition  A. 17,  property 

2,  t'  Ti  g  C2;  therefore,  t'  g  Ci  ^  C2. 

(3)  Consider  a  neutral  t  of  kind  ni  k2.  Suppose  that  for  all  t',  if  t  r',  then 
t'  g  Cl  ^C2.  Consider  rri  where Ti  gCi.  Sincen  is  strongly  normalizable, 
we  use  induction  over  j^(ti).  If  =  0,  then  tti  ^  t'ti.  But  r'n  g  C2 
(by  the  assumption  on  t'),  and  since  t  is  neutral,  no  other  reduction  is 
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possible.  If  iy{Ti)  >  0,  then  n  t[  for  somer^.  In  this  case,  rn  may 
reduce  to  either  r'n  or  to  rr{.  We  saw  that  the  first  reduct  is  in  C2.  By 
property  2  of  Definition  A. 17,  e  Ci,  also  v{t[)  <  By  the  inductive 
hypothesis  we  get  that  Tr{  e  C2.  Then  by  property  3  of  Definition  A. 17, 
rri  e  C2.  This  implies  that  r  e  Cl  ^  C2.  □ 

Definition  A. 22.  Let  x  be  the  sequence  of  all  free  kind  variables  in  kind 
K,  K  be  a  sequence  of  closed  kinds  of  the  same  length,  and  C  be  a  sequence  of 
candidates  of  the  corresponding  kinds.  Define  the  set  5«;[C/x]  of  types  of  kind 
k{k/x}  inductively  on  the  structure  of  n  as  follows: 

—if  k  =  Q.,  then  5«;[C/x]  =  Rn- 
—if  K  =  x^,  then  S^\^/x]  =  Ci. 

—if  K  =  K2,  then  5„[C/x]  =  5„JC/x]  ^  5^2  [C/x]. 

—if  K  =  Vx-  k',  then  5„[C/x]  is  the  set  of  types  r  of  kind  k{k/x}  such  that  for 

every  kind  k"  and  candi dated"  of  kind  n",  t  [k”]  g  5k/[C,C"/x,x]- 

Lemma  A. 23.  5k[C/x] /sa  reduc/b/7/fycand/dateofk/nd  k{k/x}. 

Proof  We  prove  the  statement  by  induction  on  the  structure  of  k.  For  k  =  fl, 
the  result  follows  from  Lemma  A. 19;  for  k  =  x-  directly  from  the  definition 
of5x[C/x].  \fK  =  Ki  ^  k2,  we  can  apply  the  inductive  hypothesis  on  m  and 
k2  and  Lemma  A. 21.  We  only  need  to  prove  the  case  for  k  =  Vx-  n'.  Let  x 
containing  all  the  free  kind  variables  of  k. 

(1)  Suppose  T  G  5vx.k'[C/x]-  By  Definition  A. 22,  for  any  kind  ki  and  corre¬ 
sponding  candidate  Ci,  t  [ki]  G  5„/[C,Ci/x,x]-  Applying  the  inductive  hy¬ 
pothesis  to  k',  we  get  that  S^'\C,Ci/x,x]  is  a  candidate.  Therefore,  t  [m]  is 
strongly  normalizable,  which  implies  that  r  is  strongly  normalizable. 

(2)  Suppose  T  G  5vx.k'[C/x]  and  t  ti.  For  any  kind  ki  and  corresponding 
candidateCi,  by  definition,  t[ki]  g  5„/[C,Ci/x,x]-  But  t[ki]  n  [ni].  By 
the  inductive  hypothesis  on  k'  we  have  that  5«;-[C,Ci/x,  x]  is  a  candidate; 
then  by  property  2  of  Definition  A. 17,  n  [ki]  g  5«;-[C,Ci/x,  x]-  Therefore, 
Ti  G  5vx.k'[C/x]- 

(3)  Consider  a  neutral  r  so  that  for  all  ti,  if  t  n,  then  n  g  5vx.k'[C/x]- 
Consider  an  arbitrary  kind  ki  and  a  corresponding  candidateCi.  Sincer  is 
neutral,  the  only  possible  reduction  of  r  [ki]  is  ton  [ki]-  By  the  assumption 
on  Ti  wehaverijKi]  g  5«;/[C,Ci/x,x]-  By  the  inductive  hypothesis  on  k'  it 
follows  that_5„/[C,Ci/x,x]  is  a  candidate.  By  property  3  of  Definition  A. 17, 
T  [ki]  g  [C,Ci/x,  xi-  Therefore t  g  5vx. [C/x]-  □ 

Lemma  A. 24.  5«;{«//;^/}[C/x]  =  5„[C,5«'[C/x]/x,x'] 

Proof  The  proof  is  by  induction  over  the  structure  of  k.  We  will  show  only 
the  case  for  polymorphic  kinds,  theothersfollowdirectly  by  induction.  Suppose 
K  =  Vx".  k".  Then  the  LFIS  is  the  set  of  types  r  of  kind  (Vx".  k''{k' /x'}){k/x} 
such  that  for  every  kind  and  corresponding  candidate C"',  t  [k'"]  belongs  to 
5k"{„'/x'}[C,C"7x,x"]-  Applying  the  inductive  hypothesis  to  k",  this  is  equal  to 
5k"[C,C'",5„/[C,C"7x.x"]/X!X":X']-  But  x"  does  not  occur  free  in  k'  (variables 
in  k'  can  always  be  renamed),  hence  t  7'"]  is  in  5k"[C,C'",5„/[C/x]/X)X":X']- 
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TheRHS  consi  sts  of  types  r'  of  kind  (Vx"-k"){k,  x'}  (which  isequiv- 

aient  to  (Vx".  k"{«;7x'}){«/x})  such  that  for  every  kind  k'"  and  corresponding 
candidate  C'",  r'  [k'"]  beiongsto5K"[C,5K'[C/x],C"7x:X'7X"]-  i-S-,  the  same  set 
astheLHS.  □ 

Definition  A. 25.  From  Lemma  A. 23,  we  know  that  for  every  kind  k  and 
sequences  of  variabies  x  and  candidates  C,  5„[C/x]  is  a  candidate  of  kind 
k{k/x},  that  iSn^K^n^K^Kp/x]  is  a  candidate  of  kind 
k){k/x},  that  [C/x]  is  a  candidate  of  kind  (Vx-  (x  ^  ^ 

(x^  7  ^  7{«/x}-and5(vx.n)^(vx.K)^,^[C/x]  isacandidateof  kind  ((Vx_^f^) 
(Vx-  k)  k){k/x}-  Throughout  the  rest  of  the  section,  ieavingK,  x,  andC  to  be 
determined  by  the  context,  we  define  fas  a  quadrupie  of  types  Ti„t,  t_,  tv,  and 
Tyf,  which  areeiements  of  the  above  respective  candidates. 

Lemma  A. 26.  int  e  i?n  =  ^op/xJ- 

Proof  Suffices  to  prove  that  t  =  Typerec[K{K/x}]  int  of  (f)  is  in  5„[C/k], 
whenever  f  are  constrained  by  Definition  A. 25.  The  proof  is  by  induction  on 

len{T)  =  iy{T\„t)  + 

—len{T)  =  0.  Then  r  can  reduce  only  to  T\„t,  which  is  by  Definition  A. 25  in 

57C/7«]. 

—len{T)  =  k  +  1.  Then  the  inductive  hypothesis  is  that  any  Typerec  of  length 
k  on  int  reduces  to  a  type  that  belongs  to  5„[C/x].  By  property  3  of  Defini¬ 
tion  A. 17  this  implies  that  any  Typerec  of  length  k  on  int  belongs  to  s.[c/t\- 
When  len{T)  =  fc-F  1,  we  have  that  t  either  reduces  to  Tint,  which  is  in  S.\Clx] 
by  Definition  A. 25,  or  to 

Typerec[«;{K/x}]  int  of  (t^;  t_^;  tv;  Tyf),  for  Tint  ^  t^, 

Typerec[K{K/x}]  int  of  (Tint;  t7;  tv;  Tyf),  for  t7, 

Typerec[K{K/x}]  int  of  (Tint;  t_^;  t^),  for  Ty  Ty,  or 

Typerec[K{K/x}i  int  of  (Tint;  t_^;  ry;  t^),  for  ^  t^. 

By  property  2  of  Definition  A. 17,  each  of  t;7,  t7,  7,  t^  belongs  to  the  same 
candidate  as  the  respective  initial  type.  Moreover,  the  length  of  each  of  the 
reducts  is  k.  Therefore,  by  the  inductive  hypothesis,  each  of  the  reducts  is  in 

57c/x]- 

Hence  Typerec[K{7t/x}]  int  of  (f)  always  reduces  to  a  type  in  5„[C/x].  Then  by 
property  3  of  Definition  A. 17,  Typerec[rt{K/x}]  int  of  (t)  is  also  in  5„[C/x].  Thus 

int  e  i?n.  □ 

Lemma  A. 27.  e  i?n  ^  i?n  ^  i?n  =  5n^o^a[C/x]- 

Proof  ^  G  Tin  ->  i?n  ^  if  for  all  n  g  Rq,  it  follows  that  (  ^)ti  g  Rq  ^ 
Rq.  This  is  true  if  for  all  t2  g  Rq,  it  follows  that  (^)tiT2  g  Rq.  Suffices 
then  to  prove  that  t  =  Typerec[K{K/x}]  (^)tiT2  of  (f)  is  in  5,^[C/x],  under 
the  conditions  in  Definition  A. 25.  Since  n,  t2.  Tint,  ry,  and  are  strongly 
normalizable,  we  can  proceed  by  induct!  on  on  the  length  len{T)  =  v{ti)+v{t2)  + 

J^(Tint)  -F  +  J^(Tyf). 
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—len{T)  =  0.  The  only  reduction  of  t  is  to 

t'  =  Ti  (Typerec[K{K/x}]  n  of  (t)) 

T2  (Typerec[K{K/x}]  T2  of  (t)) 

Since  both  n  and  t2  are  in  i?a,  it  follows  that  Typerec[«;{K/x}]  n  of  (r)  and 
Typ_erec[K{K/x}]  t2  of  (r)  are  in  5k[C/x].  This  implies  that  t'  also  belongs  to 

5.[C/x]. 

—len{T)  =  k  +  1.  The  case  of  the  head  reduction  is  similar  to  the  previous 
one.  The  other  possible  reductions  come  from  reducing  one  of  the  constituent 
types  Ti,  t2,  Tint,  T^,  Ty,  and  the  proofs  are  similar  to  the  proof  of  the  last 
case  in  Lemma  A. 26. 

Since  T  is  neutral,  by  property  3  of  Definition  A. 17  r  e  S.[C/%  □ 

Lemma  A. 28.  If  t  is  such  that  for  all  n  e  5^1  [C/x]  we  have  T{Ti/a}  g 
then  Aa:Ki{T/x}.r  G 

Proof  Consider  the  neutral  type  tq  =  (Aa  :  ki{t/x}.t)  ti.  We  have  that  ti 
is  strongly  normalizable  and  T{a' /a}  is  strongly  normalizable.  Therefore,  r  is 
also  strongly  normalizable.  We  proceed  by  induction  on  len{T_o)  =  v{t)  +  v{ti) 
to  prove  that  ro  always  reduces  to  a  type  that  belongs  to  [C/x] . 

—len{To)  =  0.  Therearetwo  possible  reductions.  A/3i  reduction  yields  T{Ti/a}, 
which  is  by  assumption  in  5.JC/X].  If  T  =  To  a  and  a  does  not  occur  free  in 
To,  there  is  an  rn  reduction  to  Ton;  but  in  this  case  t{ti/q;}  =  nn. 

—len{To)  =  k  +  1.  The  inductive  hypothesis  is  that  for  all  t  and  n,  if  i/{t)  + 
i^(ti)  =  fc,  Ti  G  5kJC/x],  and  Tjn/a}  G  5^2 [C/x],  then  (Aa  :  ki{k/x}-t)ti 
always  reduces  to  a  type  in  s.Acm- 

The  Pi  and  possible  r/i  reductions  are  handled  similarly  to  the  base  case. 
There  are  two  additional  reductions.  If  v{ti)  yf  0,  then  to  can  reduce  to 
(Aa:Ki{K/x}  T)  t[  where Ti  ^  t{.  By  property  2  of  Definition  A. 17,  belongs 
to5„JC/x].  TherefaeT{T{/Q;}  g  5„2[C/x].  Moreover,  i/(t)  +  :^(t{)  =  k.  Bythe 
indi^ive  hypothesis,  (Aa: ki.  t)  always  reduces  to  a  type  that_belongs  to 
‘^KsP/xj-  By  property  3  of  Definition  A.  17,  (Aa:Ki.T)  t{'  is  in  5^2 [C/x]. 
Alternatively,  if  yf  0,  then  to  can  reduce  to  (Aa  :  ki{k/x}-t')ti  where 
T  t'.  By  Lemma  A. 13,  T{Ti/a} T'ln/a}.  By  property  2  of  Defini¬ 
tion  A. 17,  T'{Ti/a}  G  5k2[C/x].  Moreover,  ^(t')  +  =  k.  Therefore,  by 

the_[nductive  hypothesis,  (Aa:«:i{T/x}.T')Ti  always  reduces  to  a  type  in 
5«;2[C/x]-  By  property  3  of  Definition  A. 17,  (Aa:«;i{T/x}.T')Ti  belongs  to 
5.2  [C/x]- 

Therefore,  the  neutral  type  tq  always  reduces  to  a  type  i  n  5.2  [C/x]-  By  property 
3  of_pefinition  A. 17,  to  g  5.2 [C/x]-  Therefore,  Aa :  ki{k/x}.t  is  in  5.JC/x]  ^ 
5.2[C/x]-  This  implies  that  Aa:Ki{7t/x}-T  belongsto5.i^.2[C/x]-  □ 

Lemma  A. 29.  V  g  5vx.(x-a)^n[C/x]. 

Proof  We  need  to  show  that  for  any  kind  ki{k/x}  and  corresponding  candi¬ 
date  Ci,  the  type  V[ki{7c/x}]  is  in  5(^^o)^a[C,Ci/x,x].  or  equivalently 

V[ki{k/x}]  G  5x^n[C,Ci/x,x]  ^  5a[C,Ci/x,  x], 
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which  follows  if  for  all  t  g  S^^q,[C,Ci/%  x]  wehaveV  [ki{k/x}]  t  g  Sn[C,Ci/%  x]- 
i.e,  V[Ki{K/x}]r  G  Rq.  For  this  to  hold,  the  type 

t'  =  Typerec[K{K/x}]  (V  [ki{k/x}]  t)  of  (r) 

must  be  in  5k[C/x]  whenever  the  conditions  in  Definition  A. 25  are  met.  Since 
each  of  thetypesT,  Tint,  t\j,  and  belongs  to  a  candidate,  they  are  strongly 
normalizable.  Thus  we  can  proceed  by  induction  on  len{T')  =  v{t)  +  + 

v{t^)  +  v{Ti)  +  v{t^)  to  prove  t'  always  reduces  to  a  type  that  belongs  to 

S.\C/% 

—len{T')  =  0.  Then  theonly  possible  reduction  of  r'  istor^  =  ry  [ki{k/x}]t  {\a\ 
ki{k/x}-t"),  where  t"  =  Typerec[K{K/x}]  Ta  of  (f).  For  all  Ti  G  Cl,  the  type 
T"{Ti/a}  reduces  to  Typerec[K{K/x}]  tti  of  (f).  By  assumption,  r  belongs  to 
5x[C,Ci/x,x]  ^  5n[C,Ci/x,x].  which  isthe  same  set  asCi^  i?n,  hencern  g 
Rii-  This  implies  Typerec[K{7^x}]  of  (T)  belongs  to 5«;[C/x].  Therefore,  by 
Lemma  A. 28  (re^acing  5kJC/x]  with  Ci  in  the  lemma),  \a-.  k,i{k/x}-t"  be¬ 
longs  to  Ci  ^  5„[C/x]. 

By  assumption  ry  g  (x-n)^(x-«)-«[C/x]-  Therefore,  ry  [ki{k/x}]  is  in 
5(x^n)^(x-«)^«[C,Ci/x,x]-  This  implies  that  Ty[Ki{K/x}]T  is  in  the  set 
%^„)^„[C,Ci/x,x]-  The  latter  is  equal  to5x^„[C,Ci/x,x]  ^  5«[C,Ci/x,  x]- 

which  in  turn  expands  to  (Ci  ^  5„[C,Ci/x,x])  ^  5„[C,Ci/x,x]-  But  x  does 
not  occur  free  in  n,  so  the  latter  can  be  written  as  (Ci  ^  5k[C/x])  ^  5k[C/x]. 
This  implies  that  t[  belongs  to 5„[C/x]. 

—len{R)  =  fc  +  1.  The  other  possible  reductions  come  from  the  reduction  of 
one  of  the  constituent  types  r,  Tim,  ry,  and  The  proof  in  this  case  is 
similar  totheproof  of  thelast  casein  Lemma  A. 26. 

Since t'  is  neutral,  by  property  3  of  Definition  A. 17  t'g5,,[C/x].  □ 

Lemma  A. 30.  If  for  B/ery  kind  n'  and  reducibility  candidate^  ofthiskind 

"tIk'/x'}  g  /x,x'],  then  Ax'.t  g  ^y^^/.^p/x]- 

Proof  Consider  the  neutral  type  t'  =  (Ax'.t)  [k']  for  an  arbitrary  kind  k'. 
Since  t{k'/x'}  is  strongly  normalizable,  t  is  strongly  normalizable,  so  we  can 
prove  the  statement  by  induction  over  v{t),  showing  that  t'  always  reduces  to 
a  type  that  belongs  to  5„[C,C7x,x'].  given  that  t{k7x'}  g  5„[C,C'/x,x7 

—v{t)  =  0.  There  are  two  possible  reductions.  A  72  reduction  yields  t{k'/x'}, 
which  is  by  assumption  in  5„[C,C'/x,x']-  If  t  =  tq  [x']  and  x'  does  not  occur 
free  in  To,  then  the ?72  reduction  yields tq  [k'].  But  inthiscaseT{K'/x'}  =  tq  [k']. 
—v{t)  =  k  +  l.  There  is  one  additional  reduction,  (Ax'.t)  [k']  (Ax'-n)  [k'], 

whereT-^Ti.  By  Lemma  A. 14,  we  know  that  t{k'/x'} ti{k'/x'}.  By  prop¬ 
erty  2  of  Definition  A. 17,  ti{k'/x'}  g  5k[C,C'/x,x']-  Moreover,  :^(ti)  =  k. 
Therefore,  by  the  inductive  hypothesis,  (Ax',  n)  [k'J  always  reduces  to  a  type 
in  /x,x']-  By  property  3  of  Definition  A. 17,  (Ax'.n)  [k']  belongs  to 

57c,c'/x,x7 

Therefore,  the  neutral  type  t'  alwaysjeduces  to  a  type  in  5„[C,C'/x,x']-  By 
property  3  of  Definition  A. 17,  t'  g  5k[C,C'/x, x']-  Therefore,  Ax'.t  belongs  to 

5y;,y7C/x].  □ 
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Lemma  A. 31.  Ifr  g  Sy^,K,[C/x],  then  for  &/ery  kind  n'  wehaver  [k'{k/x}]  g 
^k{k'/x}  P/ k]- 

Proof  By  Definition  A. 22  t  [k'{k/x}]  belongs  to  5k[C,C7x5X]-  for  every  kind 
k'  and  reducibility  candidate  C'  of  this  kind.  Set  C  =  5k'[C/x].  Applying 
Lemma  A. 24  leads  to  the  result.  □ 

Lemma  A. 32.  V+g  5(vx.n)^n[C/x]- 

Proof  We  need  to  show  that  for  all  r  g  5vx.n[C/x]  we  have  vV  g  Rn-  The 
latter  holds  if  r'  =  Typerec[K{7t/x}]  (vV)  of  (f)  belongs  to  5«;[C/x]  under  the 
conditions  in  Definition  A. 25.  We  will  prove  by  induction  on  fen(r')  ee  v{t)  + 
v{Tmi)  +  +  v{t^)  that  the  type  Typerec[K{K/x}]  (vV)  of  (t)  always 

reduces  to  a  type  i  n  s.\c/% 

—len{T')  =  0.  Then  the  only  possible  reduction  of  r'  istor.^r(Ax.  r"),  where 
t"  =  Typerec[K{K/x}]  (j  [x])  of  (T)-  For  an  arbitrary  kind  k',  t"{k!  jx}  is  equal 
toTyperec[K{K/x}]  r  [k']  of  (f).  By  the  assumption  on  r,  wegetthat  t  [k']  g  Rq. 
Therefore,  by  Definition  A. 18  t"{k7x}  g  ‘S’^P/x]-  Si  nee  x  does  not  occur  free 
in  K,  we  can  write  this  as  t”{k' /x}  g  x]  for  any  candidate  C  of 

kind  k'.  Thus  by  Lemma  A.30  Ax- t"  g  5vx.k[C/x]-  By  the  assumptions  on 
Tyf  and  T,  is  in  5^,[C/x]. 

—len{T')  =  k  +  1.  The  Other  possible  reductions  come  from  the  reduction  of 
one  of  the  constituent  types  r,  ript,  t_,  ry,  and  The  proof  in  this  case  is 
similar  totheproof  of  thelast  casein  Lemma  A. 26. 

Since  t'  is  neutral,  by  property  3  of  Definition  A. 17,  t'g57C/x].  □ 

We  now  come  to  the  main  result  of  this  section. 

Theorem  A. 33  (Candidacy).  Ldt  t  be  a  type  of  kind  k.  Suppose  aii  the 
free  type  variabies  of  t  are  in  ai...an  of  kinds  ki  . . .  and  aii  the  free  kind 
variabies  of  k,  ki...  are  among  xi  ■  •  ■  Xm-  /  f_Ci  ...Cm  are  candidates  of 
kinds  k[...  k7  and  n  . . .  are  types  of  kind  Ki{iC/x}  ■  ■  •  UnW/x}  which  are 
in  [C/x] . . .  [C/x],  then  T{)7/x}{r/a}  beiongs  to  5«[C/x]. 

Proof  The  proof  is  by  i  nduction  over  the  structure  of  t. 

The  cases  of  int,  V,  are  covered  b^Lemmas  A. 26,  A. 27,  A. 29,  and  A. 32. 

Suppose  T  =  a*  and  k  =  k^.  Then  T{iC/x}{T/a}  =  n.  By  assumption,  this 
belongs  to  5«;JC/x]. 

Suppose  T  =  r7  Then  t[  is  of  kind  k'  k  and  of  kind  n'  for  some 
kind  k'.  By  the  inductive  hypothesis,  T{{/7'/x}{T/a}  belongs  to  [C/x]  and 
'r2W /x}{T/a}  belongs  to5«;/[C/x].  Therefore,  /x}{T/a})  /xiiT/a}) 
isin5„[C/x]. 

Suppose  r  =  Then  r'  is  of  kind  Vxi-ki  for  some  xg^^C  also  k  = 

ki{k' Ixi}-  By  the  inductive  hypothesis,  t' {ic /x}{t /a}  belongs  to [C/x] ■ 
By  Lemma  A.31  T'{)7/x}{r/a}  [k'K/xI]  is  in  5«,i{«:'/xi}P/x].  which  is  equiva¬ 
lent  to5«;[C/x]. 

Suppose  T  =  Typerec[K]  t'  of  (Tint;  ry;  r^f).  Then  the  kinds  of  r'.  Tint,  T^, 

Ty,  and  Tyf  are  Cl,  k,  Cl  ^  k  Cl  k  ^  k,  Vx-  (x  ^  ^  (x  ^  r:)  — >  k,  and 
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{type  context)  C  ::=  []  |  Ax.C  |  C  [k]  |  \a:K.C  \  C  t  \  t  C 
I  Typerec[K]  C  of  (Tin,;  tv;  r^) 

I  Typerecf/t]  r  of  (C;  r^;  ry;  t^)  |  Typerec[K]  r  of  (Tint;  C;  ry;  r^) 

I  Typerecf/t]  r  of  (rint;  r^;  C;  t^+)  |  Typerec[K]  t  of  (Tint;  "ry;  C) 

Fig.  22.  Type  contexts 


^  (Vx-k)  ^  K,  respectively.  By  the  inductive  hypothesis  we  have 

t' {t^/x}{T /a}  G  i?n_ 

TintW/x}{^/a}  G  S^,[C/x\ 
f^{t^/x}{T/a}  G  5n^K^n^tt^/T[C/x] 

T-vK/xIlT/a}  G 

V{'«Vx}{i"/a}  G  5(vx.n)^(Vx.K)^«[C/x] 

Then  by  definition  of  Rn, 

Typerec[K{KVx}]  t' {k' /x}{t /a}  of  (riptK/x}{T/a}; 

T-K/x}{^/a}; 

fvl^Vxll^/a}; 

V{«Vx}{f"/a}) 

belongs  to  5tt[C/x]. 

Suppose T  =  \a'  -.k' .Ti.  Then  ti  has  some  kind  k"  such  that  k  =  k'  —>  k” ,  and 
the_free  type  variables  of  Ti  are  in  ai,...,  By  the  inductive  hypothesis, 

Ti{i^ /x}{f,T' /a,a'}  is  in  5k"[C/x],  wherer'  is  of  kind  n'{i^/x}  and  belongs  to 
5„/[C/x].  This  implies  that  (Ti{^/x}{r/a}){r7a'}_belongs  to  5«;»[C/x]  (since 
a'  occurs  free  only  in  ti).  By  Lemma  A. 28,  Aa' Vx}-  (nlft'/xliT/a})  is  in 

Suppose  T  =  Ax'.t'.  Then  the  kind  of  t'  is  n” ,  and  n  =  Vx'  k".  By  the 
inductive  hypothesis,  t'{^,  K7x.x'}{T/a}  belongs  to  5k''[C,C7X)X']  for  an  ar¬ 
bitrary  kind  k'  and  candidate  C'  of  kind  k'.  Since  x'  occurs  free  only  in  t',  we 
get  that  (r'{^/x}{T/a}){K7x'}  is  in  5„//[C,C7X)X']-  By  Lemma  A. 30  the  type 
Ax'-  {t' {n' /x}{t /a})  is  in  5vx'.k"[C/x].  □ 

Suppose  S'iVj  is  the  set  of  strongly  normalizable  types  of  kind  k*. 

Corollary  A. 34.  AH  types  are  strongly  normalizable 

Proof  FollowsfromTheorem  A. 33  by  setting  Cj  =  S'A^i  and  Ti  =  a*.  □ 

A.3  Confluence  in  the  Type  Language 

To  prove  confluence  of  the  reduction  in  the  type  language  of  A we  first  define 
the  compatible  extension  of  the  one-step  reduction  Let  the  set  of  type 
contexts  (ranged  over  by  C)  be  defined  inductively  as  shown  in  Figure  22.  A 
context  is  thus  a  "type  term"  with  a  hole  [];  the  term  CIt}  is  defined  as  the 
type  obtained  by  replacing  the  hole  in  C  byr. 

Definition  A. 35.  n  i->  r2  iff  there  exist  types  7  and  and  a  type  context 
C  such  that  n  =  C{t[},  t2  =  Clr^},  and  7  7. 
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Let  as  usual  denote  the  reflexive  and  transitive  closure  of 

Lemma  A. 36.  Ifr  t',  then  C{t}  C{t'}. 

Proof  From  compositional ity  of  contexts,  i.e.,  since  for  all  contexts  Ci  and 
C2  and  types  r,  C'i{C'2{r}}  =  C{t}  for  some  context  C,  which  is  constructed 
inductively  on  the  structure  of  Cl.  □ 

Corollary  A. 37.  Ifr  1-^*  t',  then  C{t}  1-^*  C{t'}. 

The  following  lemmas  are  proved  by  induction  on  the  structure  of  contexts. 

Lemma  A. 38.  /f ti  h- >  t2,  then  Tijr/a}  r2{r/a}. 

Proof  Sketch  Follows  from  Lemma  A.  13.  □ 

Lemma  A. 39.  /f ti  1— >  t2,  than  ti{k/x}  t2{k/x}- 

Proof  Sketch  Follows  from  Lemma  A.  14.  □ 

Lemma  A. 40.  lf£;A  h  C{r}  :  k,  then  there  exist  A',  and  k'  such  that 
£'\  A'  h  T  :  k';  furthermore  if£'\  A'  \-  t'  ■.  k',  then  £;A\-  C{t'}  ■.  k. 

By  induction  on  the  structure  of  types  we  prove  the  following  substitution 
lemmas. 

Lemma  A. 41.  lf£;A,a:K'\-T  :  k  and  tT;  A  h  r'  :  k',  then  A  h  t\t'  j cx\  : 

K. 

Lemma  A. 42.  lf£,x]A  h  t  :  k  and  £  h  C,  then  £;A{k'/x}  F  t{k'/x}  ■ 
k{k'/x}- 

Now  we  can  show  subject  reduction  for 

Lemma  A. 43.  lf£;A  h  r  :  k  and  t t',  then  £;A\~t'  :  k. 

Proof  Sketch  Follows  by  case  analysis  of  the  reduction  relation  ^  and  the 
substitution  Lemmas  A. 41  and  A. 42.  □ 

Then  we  have  subject  reduction  for  asa  corollary  of  Lemmas  A. 43  and  A.40. 

Corollary  A. 44.  lf£;A  h  t  :  k  and  t  t',  than  £;A\-  t'  :  k. 

For  our  confluence  proof  we  need  another  property  of  substitution. 

Lemma  A. 45.  /f ti  t2,  than  t{ti/q;}  r{r2/Q;}. 

Proof  The  proof  is  by  induction  on  the  structure  of  t.  The  cases  when  r  is  a 
constant,  t  =  a,  or  t  =  /S  ^  a,  are  straightforward. 

case  T  =  Ax-r':  W.I.o.g.  assume  that  x  is  not  free  in  n,  so  that  rjTi/a}  = 
Ax-  {r'ln/a})-,  then  by  subject  reduction  (Corollary  A. 44)  x  is  not  free  in  t2, 
hence  T{T2/a}  =  Ax-  {T'{T2/a}).  By  the  induction  hypothesis  we  have  that 
T'{Ti/a}  1-^*  r'{T2/Q;}.  Then  by  Corollary  A.37  for  the  context  Ax- []  we  obtain 
Ax-  {r'in/a})  Ax-  (r'lra/a}). 

The  cases  of  T  =  r'  [k]  andr  =  xp-.K.r'  are  similar. 
caseT  =  T'T":  By  induction  hypothesis  we  have 

(1)  T'{ri/a}  1-^*  r'{T2/Q;} 

(2)  r"{Ti/a}  1-^*  r"{T2/a}. 
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Using  context  []  {T"{Ti/a}),  from  (1)  and  Corollary  A. 37  it  follows  that 

T{Ti/a}  =  (r'ln/a})  (r"{Ti/a})  (T'{T2/a})  (/'{n/a}); 

then  using  context  (t'{t2/q;})  [],  from  (2)  and  Corollary  A. 37  we  have 

(r'{r2/a})  (r"{Ti/a})  (/{ra/a})  ((r"{r2/a}))  =  r{T2/a} 

and  the  result  follows  si  nee  is  closed  under  transitivity. 

The  case  of  T  =  Typerec[«:]  t'  of  (Tint;  ry;  r^f)  is  similar.  □ 

The  next  step  is  to  prove  local  confluence  of  the  reduction  of  well-formed 
types. 


Lemma  A. 46.  lf£;A  \-  t  :  kq,  t  ^  n,  and  t  ^  t2,  then  thereexists tq  such 
that  Ti  1-^*  To  and  t2  tq. 

Proof  The  proof  proceeds  by  induction  on  the  structure  of  the  derivation  of 
A  h  T  :  Ko-  For  the  base  cases,  corresponding  to  t  being  one  of  the  con¬ 
structors  or  a  type  variable,  no  rules  of  reduction  apply,  so  the  result  is  trivial. 
For  the  other  cases,  let  (71,(72, t{,t2,t",  and  t!^  be  such  that  t  =  Ci{t[}  = 
C2{t2},  Ti  =  (7i{t"},  T2  =  (72{t2  },  and  t[  ^  t",  T2  . 

case  T  =  Ax- t':  An  inspection  of  the  definition  of  contexts  shows  that  the 
only  possible  forms  for  (7i  and  C2  are  []  and  Ax-  (7.  Thus,  accounting  for  the 
symmetry,  there  are  the  fol  lowi  ng  three  subcases: 

—Both  Cl  and  C2  are  [].  The  only  reduction  rule  that  applies  then  is  772,  so 

n  =  t2. 

—Cl  =  Ax-C'i  and  C2  =  Ax- (7^.  Then  the  result  follows  by  the  inductive 
hypothesis  and  Corollary  A. 37. 

—Cl  =  []  and  C2  =  Ax.C'2,.  Again,  the  only  reduction  for  t(  is  772,  sot'  =  t"  [x] 
for  some  t".  Then  there  are  two  cases  for  First,  if  (7^  =  [],  then  =  t', 
and— by  inspection  of  the  rules— in  the  case  of  kind  application  the  only 
possible  reduction  is  via  (32,  hence  t"  =  Ax',  t'"  for  some  x'  and  t'".  Repre¬ 
senting  the  reductions  diagrammatical  I  y,  we  have  immediate  confluence  (up 
to  renaming  of  bound  variables): 


Ax.  {{Ax',  r'")  [x]) 


Ax'.t'"=„  Ax.t'"{x/x'} 


The  second  case  accounts  for  all  other  possibilities  for  (7^  (which  must  be  of 
the  form  (7^'  [x])  and  reduction  rules  that  can  be  applied  in  t"  =  C'^Ht^}  to 
reduce  it  (by  assumption)  to  which  we  denote  by  t^'.  The  dashed 
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arrows  show  the  reductions  that  complete  local  confluence. 


Ax-  {r"  M) 


r 


// 


Ax-(5[X]) 


case  T  ^  t'  [k]:  Again  by  inspection  of  the  rules  we  have  that  the  contexts 
are  either  empty  or  of  the  form  C  [k].  The  symmetric  cases  are  handled  as  in 
the  case  of  kind  abstraction  above.  The  interesting  situation  is  when  Ci  =  [] 
and  C2  =  C2  [k].  The  only  reduction  rule  that  applies  for  ri  is  then  P2,  hence 
r'  =  Ax-  t"  for  some  x  and  r".  Again  we  have  two  major  cases  for  t2‘.  first,  if 
C2  =  [],  only  ?72  applies,  sor"  =  r'"  [x]  for  somer'",  thus 


(Ax.t'"[x])M 


r'"  [X]{«^/X}  =  r'"  [«] 


I  n  all  other  cases  we  have  =  Ax-  C2 ,  so  t"  =  {r^}  1-^  letting 

stand  for  the  latter,  we  have  the  diagram 


(Ax-t")  W 


r"{^/x}  (Ax-r'OW 

Lemma  A. 3^  ^  Qi 

"r'YiKlx} 

case  T  =  Xa:  k.t'\  The  contexts  can  be  either  empty  or  of  the  form  Aa  :  n.  C. 
The  symmetric  cases  are  similar  to  those  above.  I  n  the  case  when  Ci  =  [] 
and  C2  =  Xa:  K.C2,  the  only  rule  that  applies  for  the  reduction  of  is  771,  so 
t'  =  r"  a  for  some  r".  Again,  there  are  two  cases  for  First,  if  =  [],  we 
have  =  t'  =  t"  a,  and  the  only  reduction  rule  for  application  is  /3i,  hence 
t"  =  Xa'  :  k'.t'"  for  some  a',K',  and  t'".  Since  A  h  r  :  kq,  the  subterm 
(Aa'  :  k'.t'")  a  must  be  well-typed  in  an  environment  assigning  kind  k  to  a, 
hence  k'  =  k,  so  that 


Aa :  K.  ((Aa' :  k.  t'")  a) 


Xa' :  K.  t'"  =a  Xa :  k.  T'"{a/a'} 
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I  n  all  other  cases  for  (which  are  of  the  form  a),  we  have  t"  =  ^ 

C2  {T2'};  denoting  the  latter  type  by  we  obtain 


Xa:K.  (r"  a) 


Xa:K.  (tq'  a) 


caser  =  r'r":  There  are  three  possibilities  for  the  contexts  Cl  and  C2:  to  be 
empty,  of  the  form  Cr',  or  of  the  form  rC.  The  symmetric  cases  proceed  as 
before. 

When  Cl  =  C[t''  and  C2  =  r'C^,  the  redexes  in  and  T2  are  in  different 
subterms  of  the  type,  hence  the  reductions  commute:  we  have  C[{t[}  =  r' 
and  c^r^  =  r",  therefore  n  =  (CUr"})  (C^r^)  and  r2  =  (C^r"}), 

which  both  reduce  to  (C({t{'})  (C^It^'}). 

When  Cl  =  []  and  C2  =  C^t",  the  only  reduction  rule  that  applies  for  = 
t' t"  is  I3i,  hence  t'  =  Xa:  k.  t'"  for  some  a,  k,  and  t'".  As  before,  there  are  two 
cases  for  C2.  If  it  isempty  then  the  only  reduction  rulethat  applies  tor^^  =  r' 
is?7i,  hence  r'"  =  a  for  somer^'",  and  local  confluence  follows  by 


{Xa:K.  a))  r" 


/3i 


>71 


Alternatively,  C2  must  be  of  the  form  Xa  :  k.C'^,  where  C2{r2}  =  r"'.  Then 

t"'  ^  C2  {t2  }  =  Tq',  and  we  have 


{Xa:K.T'")T" 


When  Cl  =  []  and  C2  =  r'C^,  again  the  only  reduction  rulethat  applies  for 
=  r'r"  is  Pi,  sot'  =  Xa:K.T'"  for  somea,  k,  and  t'".  This  time,  regardless  of 
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the  structure  of  C2,  we  have  that  r"  =  {r^}  1-^  hence 


(Aa:K.r"')r" 


Lemma  A.4B  /3i 


r'"{r"/a} 


case  r  =  Typerec[K]  r'  of  (rint;  ry;  T^f):  The  contexts  can  be  empty  or  of  the 
forms 

Typerec[«;]  C  of  (Tint;  ry;  r^f) 

Typerec[«;]  r'  of  (C;  ry;  r^f) 

Typerec[«;]  r'  of  (rint;  C;  ry;  r^f) 

Typerec[«;]  r'  of  (rint;  t_^;  C;  r^f) 

Typerec[«;]  r'  of  (rint;  ;  ry;  C) 

The  symmetric  cases  and  the  non-overlapping  cases  are  handled  as  before. 
Accounting  for  the  symmetry,  the  remaining  cases  are  when  Ci  =  []  and  (72  is 
not  empty.  Then  the  reduction  ruleforT{  must  beoneof  andf4-  Since 

there  is  nor?  rule  for  Typerec,  the  prcxjfs  are  straightforward, 
subcase  fi:  then  r'  =  int.  The  result  of  the  reduction  under  is  ignored  and 
local  confluence  is  trivial,  unless  Ci  =  Typerec[«:]  t'  of  (C'^\  r_^;  ry;  Tyt).  I  n  the 
latter  case. 


Typerecl^]  int  of  (rint;  r_^;  ry;  r^f) 


subcase  then  r'  =  r"  ^  r'".  We  will  use  Typerec[K]  r'  of  r  as  a  short¬ 
hand  for  Typerec[«:]  r'  of  (rint;  r_^;  ry;  r^),  and  similarly  for  contexts.  If  (72  = 
Typerec[K]  (7^  of  r,  then  there  are  two  subcases  for  C'^  (which  must  have  the  ^ 
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constructor  at  its  head).  Thus,  if  C'^  =  C'^ 

Typerec[At]  (r" 
*2 


t"  (Typerec[K]  t"  of  r) 


(Typerec[«:]  r'"  of  t) 


Lemma  A. 45^ 


t'")  ofT 


r_^  Tg'  (Typerec[K]  Tq'  of  r) 
t'"  (Typerec[K]  t"'  of  t) 


wherer"  =  ^  =  Tq.  The  case  of  =  r"  ^  C'^  issimilar. 

Of  the  other  cases  we  will  only  show  the  reduction  in  the  position  of  t_ 
writing?^ for  r_^o;  ry;  v),  where t_^o. 


Typerec[«;]  {t'‘ 
t2 


t'")  ofT 


t"  (Typerec[K]  t"  of  r) 
t'"  (Typerec[«:]  r'"  of  t) 

•v. 

Lemma  A. 45^ 


t'")  of  7^ 


T_^o  t"  (Typerec[K]  r"  of  Tff) 
t'"  (Typerec[K]  r'"  of  Tg) 


subcasesfg  and  f4  aresimilar  tof2-  □ 

Corollary  A. 47.  /ff;  A  h  t  :  k,t^*v,  and  t  r',  then  r' 

Theorem  A. 48.  lf£;A  \-  t  :  n,  then  there  exists  exactly  one  i'  such  that 

T  V. 

Proof  From  Corollaries  A. 34  and  A. 47.  □ 
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